Нет. Вы в очередной раз демонстрируете свою альтернативную одаренность. Но проблема Habr-а в том, что здесь не принято альтернативно одаренным персонажам указывать на их альтернативную одаренность. Хотя при общении с вами, например, аргументы ad hominem гораздо более уместны, чем попытки объяснить как устроен реальный мир.
C++ стал полигоном, но не таким, как ML и Haskell. Сделанное в C++ обкатывалось на практике на миллионах программистах и миллиардах строк кода. То, что было сделано в C++ нашло широкое применение и показало благодаря этому что получилось хорошо, что нет.
В отличии от загончиков, вроде Haskell.
Но вы, из своей параллельной вселенной, можете видеть все что угодно. И думать, что уже что-то поняли. Считать, что шаблоны в C++ нужны только для шуток, головоломок и job security.
Только тут полигоны (о которых шла речь изначально) ни при чём.
Это в вашем манямирке.
Востребована и широко использована была совместимость с C, не более.
Если бы была востребована только совместимость с Си, то шаблоны в C++ никто бы не использовал. А они стали широко использоваться с середины 1990-х. И в рамках C++ эта реализация параметрического полиморфизма полностью и многократно доказала свою состоятельность.
О требованиях к полигонам мы согласны в итоге или нет?
Нет. Меня интересуют инструменты, которые широко применяются на практике, которые можно брать и использовать. C++ стал таким инструментом. Кому-то параметрический полиморфизм в C++ может казаться чем-то (или не казаться), но история показала, что это было востребовано и широко использовано. В отличии от.
Я так понимаю, что сейчас общаюсь с молодым человеком, который потратил всю юность и молодость на изучение C++, а потом горько пожалел об этом и опубликовал на Хабре статью про свое разочарование под другим ником.
Полигон — это когда массовое применение прямо там же, да.
Массовое применение Haskell-я и ML?
Простите, но мне не интересны новости из параллельных вселенных. Как и ответы на выдуманные вами самими вопросы.
Не двигайте гоалпосты.
В вашем уютном манямирке, в котором Haskell уже массово применяется, возможно, и не знают про то, что не следует указывать людям что им делать, чтобы людям не пришлось указывать вам направление движения.
В C++ обкатывали разве что идею «как бы параметрический полиморфизм сделать максимально криво, но чтобы потом было весело делать головоломки и отсеивать людей на интервью»
Интересно, а где в 1990-ом году это было сделано "максимально прямо" и почему эти мощные конкуренты (если они вообще были) до массового применения так и не дошли?
Моя личная проблема с чтением всех подобных обзорных статей -- это то, что примеры все какие-то слишком мелкие, тривиальные и, если так можно выразиться, притянутые за уши. Ну т.е. понятно, что что-то сложное вставлять в обзорную статью в стиле "галопом по Европам" нет смысла, т.к. это серьезно "утяжелит" материал. Но, с другой стороны, сложно понять из таких мало кому нужных в реальной жизни примеров в чем же профит.
Интересно было бы посмотреть на использование всей этой кухни в чем-то посерьезнее. Может есть какие-то открытые проекты, в которых подобное уже применяется?
А я вам приводил примеры реальной практики программирования.
От вас были только общие слова и ссылки на репозитории со студенческим гонокодом.
Вы, кстати, сами читали статью, на которую ссылки дали? В частности раздел про инкапсуляцию, в которой копипаста из описания понятия "модуля" из модульного программирования.
Инкапсуляция – это принцип изоляции контрактных обязательств объекта от его реализации.
Во-первых, посмотрите определение инкапсуляции хотя бы в Wikipedia, самый первый абзац. Про изоляцию контракта от реализации -- это вам в модульное программирование и абстрактные типы данных.
Во-вторых, мы говорим про C++, в котором у инкапсуляции есть вполне конкретное воплощение.
В-третьих, я вас еще раз призываю завязывать с бла-бла-бла и сконцентрироваться (если сможете) на предоставлении хоть каких-либо объективных подтверждений своим высказанным выше утверждениям.
Ну или продолжайте зарабатывать себе репутацию балабола. Видимо вам это зачем-то нужно.
а её внутреннее устройство мы не имеем права учитывать согласно воспетому вами принципу инкапсуляции
Инкапсуляция -- это про то, что доступ к данным объекта имеют только методы объекта. А не про то, что инкапсуляция напрочь скрывает принципы реализации.
Динамический вектор остается динамическим вектором. Хэш-таблица -- хэш-таблицей, сбалансированное двоичное дерево -- сбалансированным двоичным деревом. Их свойства останутся при них вне зависимости о того, базе ООП реализуются эти понятия или на базе старого доброго структурного программирования.
На Си никто ж не будет реализовывать ООП без очень веских причин.
Для альтернативно одаренных повторю еще раз: вы сказали о неких накладных расходах в C++. Сказанное не мешало бы подтвердить хоть какими-то количественными показателями.
Вы упорно не можете. Вы упорно демонстрируете свою глупость. Если вам нравится публично позориться, то почему бы и не продолжить окунать вас в ваши же продукты.
Например, вектор векторов не образует в памяти регулярную структуру, такую как массив массивов
Вы настолько глупы, чтобы врать когда все ходы записаны?
PS. Если вы не поняли, а есть ощущение, что не поняли от слова совсем, то под утверждениями подразумевались в первую очередь вещи, вроде: "на реализацию ООП в C++ уходит гораздо больше оверхеда (по сравнению с С)"
Вопрос был про вектор, но вы не стали отвечать про вектор, вы откуда-то вытащили задачу про массив. Тогда как вектор -- это не массив. Вектор может использоваться для организации двумерного массива в виде вектора векторов, но к моему вопросу это отношения не имеет.
Если уж вы заговорили про массив на базе вектора векторов, то вот вам примитивная реализация элементарного примера на чистом Си, без ООП и инкапсуляции:
Попробуйте найти принципиальные отличия в ассемблерном коде, который компилятор сгенерировал для функции index_of_max_column.
И если уж вам так припекают накладные расходы на std::vector, то попробуйте изобразить его аналог на чистом Си на простых структурах и свободных функциях. А потом с помощью этой реализации сделайте нужную вам двумерную матрицу на базе вектора векторов. И расскажите читателям этого флейма куда же денется регулярная структура в памяти и все прочее. Ведь ни ООП, ни инкапсуляции в вашей реализации не будет, а результат окажется таким же.
Простите, но вашей глупости, выражающейся в афигительных формулировках, с меня достаточно. Ваша фраза -- "в реальной прикладной программе на C++ такой структуры matrix не будет" -- не содержит никаких ограничений, т.е. может трактоваться как "в любой реальной программе".
Так вот, не в любой. Отсюда и просьба к вам не говорить за всех, т.е. вводить ограничения в ваши высказывания. Чтобы можно было понять, что речь идет о "виденных вами лично" программах на C++, или о "написанных вами лично программах на C++", или о специально раскопанных вами на помойках фрагментах говнокода на C++, про который забыли даже его авторы.
Нет. Вы в очередной раз демонстрируете свою альтернативную одаренность. Но проблема Habr-а в том, что здесь не принято альтернативно одаренным персонажам указывать на их альтернативную одаренность. Хотя при общении с вами, например, аргументы ad hominem гораздо более уместны, чем попытки объяснить как устроен реальный мир.
Вы себе льстите.
C++ стал полигоном, но не таким, как ML и Haskell. Сделанное в C++ обкатывалось на практике на миллионах программистах и миллиардах строк кода. То, что было сделано в C++ нашло широкое применение и показало благодаря этому что получилось хорошо, что нет.
В отличии от загончиков, вроде Haskell.
Но вы, из своей параллельной вселенной, можете видеть все что угодно. И думать, что уже что-то поняли. Считать, что шаблоны в C++ нужны только для шуток, головоломок и job security.
Как я уже сказал, новости из параллельной вселенной меня не интересуют.
Это в вашем манямирке.
Если бы была востребована только совместимость с Си, то шаблоны в C++ никто бы не использовал. А они стали широко использоваться с середины 1990-х. И в рамках C++ эта реализация параметрического полиморфизма полностью и многократно доказала свою состоятельность.
Нет. Меня интересуют инструменты, которые широко применяются на практике, которые можно брать и использовать. C++ стал таким инструментом. Кому-то параметрический полиморфизм в C++ может казаться чем-то (или не казаться), но история показала, что это было востребовано и широко использовано. В отличии от.
Я так понимаю, что сейчас общаюсь с молодым человеком, который потратил всю юность и молодость на изучение C++, а потом горько пожалел об этом и опубликовал на Хабре статью про свое разочарование под другим ником.
Массовое применение Haskell-я и ML?
Простите, но мне не интересны новости из параллельных вселенных. Как и ответы на выдуманные вами самими вопросы.
В вашем уютном манямирке, в котором Haskell уже массово применяется, возможно, и не знают про то, что не следует указывать людям что им делать, чтобы людям не пришлось указывать вам направление движения.
Интересно, а где в 1990-ом году это было сделано "максимально прямо" и почему эти мощные конкуренты (если они вообще были) до массового применения так и не дошли?
Моя личная проблема с чтением всех подобных обзорных статей -- это то, что примеры все какие-то слишком мелкие, тривиальные и, если так можно выразиться, притянутые за уши. Ну т.е. понятно, что что-то сложное вставлять в обзорную статью в стиле "галопом по Европам" нет смысла, т.к. это серьезно "утяжелит" материал. Но, с другой стороны, сложно понять из таких мало кому нужных в реальной жизни примеров в чем же профит.
Интересно было бы посмотреть на использование всей этой кухни в чем-то посерьезнее. Может есть какие-то открытые проекты, в которых подобное уже применяется?
От вас были только общие слова и ссылки на репозитории со студенческим гонокодом.
Вы, кстати, сами читали статью, на которую ссылки дали? В частности раздел про инкапсуляцию, в которой копипаста из описания понятия "модуля" из модульного программирования.
А эти подтверждения сейчас здесь с нами, в этом обсуждении? А то примеры кода с ассемблерным выхлопом здесь приводили вовсе не вы.
Во-первых, посмотрите определение инкапсуляции хотя бы в Wikipedia, самый первый абзац. Про изоляцию контракта от реализации -- это вам в модульное программирование и абстрактные типы данных.
Во-вторых, мы говорим про C++, в котором у инкапсуляции есть вполне конкретное воплощение.
В-третьих, я вас еще раз призываю завязывать с бла-бла-бла и сконцентрироваться (если сможете) на предоставлении хоть каких-либо объективных подтверждений своим высказанным выше утверждениям.
Ну или продолжайте зарабатывать себе репутацию балабола. Видимо вам это зачем-то нужно.
ХЗ, это вы приплели сюда этот пример, у себя и спрашивайте.
К ООП это вообще не имеет отношения.
Инкапсуляция -- это про то, что доступ к данным объекта имеют только методы объекта. А не про то, что инкапсуляция напрочь скрывает принципы реализации.
Динамический вектор остается динамическим вектором. Хэш-таблица -- хэш-таблицей, сбалансированное двоичное дерево -- сбалансированным двоичным деревом. Их свойства останутся при них вне зависимости о того, базе ООП реализуются эти понятия или на базе старого доброго структурного программирования.
Для альтернативно одаренных повторю еще раз: вы сказали о неких накладных расходах в C++. Сказанное не мешало бы подтвердить хоть какими-то количественными показателями.
Вы упорно не можете. Вы упорно демонстрируете свою глупость. Если вам нравится публично позориться, то почему бы и не продолжить окунать вас в ваши же продукты.
Некто @vadimr чуть выше:
Вы настолько глупы, чтобы врать когда все ходы записаны?
PS. Если вы не поняли, а есть ощущение, что не поняли от слова совсем, то под утверждениями подразумевались в первую очередь вещи, вроде: "на реализацию ООП в C++ уходит гораздо больше оверхеда (по сравнению с С)"
Помилуйте, я вообще не рассуждаю, а всего лишь:
призываю вас подкреплять свои высказывания хоть какими-либо подтверждениями;
указываю на явные проблемы в ваших "утверждениях".
Вопрос был про вектор, но вы не стали отвечать про вектор, вы откуда-то вытащили задачу про массив. Тогда как вектор -- это не массив. Вектор может использоваться для организации двумерного массива в виде вектора векторов, но к моему вопросу это отношения не имеет.
Если уж вы заговорили про массив на базе вектора векторов, то вот вам примитивная реализация элементарного примера на чистом Си, без ООП и инкапсуляции:
https://godbolt.org/z/KrY3P7neK
А вот реализация этого же примера на C++ с классами и переопределением оператора квадратных скобочек:
https://godbolt.org/z/xGdfMGz8o
Попробуйте найти принципиальные отличия в ассемблерном коде, который компилятор сгенерировал для функции index_of_max_column.
И если уж вам так припекают накладные расходы на std::vector, то попробуйте изобразить его аналог на чистом Си на простых структурах и свободных функциях. А потом с помощью этой реализации сделайте нужную вам двумерную матрицу на базе вектора векторов. И расскажите читателям этого флейма куда же денется регулярная структура в памяти и все прочее. Ведь ни ООП, ни инкапсуляции в вашей реализации не будет, а результат окажется таким же.
Если честно, то глубина вашей глупости.
Простите, но вашей глупости, выражающейся в афигительных формулировках, с меня достаточно. Ваша фраза -- "в реальной прикладной программе на C++ такой структуры matrix не будет" -- не содержит никаких ограничений, т.е. может трактоваться как "в любой реальной программе".
Так вот, не в любой. Отсюда и просьба к вам не говорить за всех, т.е. вводить ограничения в ваши высказывания. Чтобы можно было понять, что речь идет о "виденных вами лично" программах на C++, или о "написанных вами лично программах на C++", или о специально раскопанных вами на помойках фрагментах говнокода на C++, про который забыли даже его авторы.
Нет, не ответили.
А теперь еще раз, может быть сейчас поймете: отучаемся говорить за всех.