А я вам приводил примеры реальной практики программирования.
От вас были только общие слова и ссылки на репозитории со студенческим гонокодом.
Вы, кстати, сами читали статью, на которую ссылки дали? В частности раздел про инкапсуляцию, в которой копипаста из описания понятия "модуля" из модульного программирования.
Инкапсуляция – это принцип изоляции контрактных обязательств объекта от его реализации.
Во-первых, посмотрите определение инкапсуляции хотя бы в Wikipedia, самый первый абзац. Про изоляцию контракта от реализации -- это вам в модульное программирование и абстрактные типы данных.
Во-вторых, мы говорим про C++, в котором у инкапсуляции есть вполне конкретное воплощение.
В-третьих, я вас еще раз призываю завязывать с бла-бла-бла и сконцентрироваться (если сможете) на предоставлении хоть каких-либо объективных подтверждений своим высказанным выше утверждениям.
Ну или продолжайте зарабатывать себе репутацию балабола. Видимо вам это зачем-то нужно.
а её внутреннее устройство мы не имеем права учитывать согласно воспетому вами принципу инкапсуляции
Инкапсуляция -- это про то, что доступ к данным объекта имеют только методы объекта. А не про то, что инкапсуляция напрочь скрывает принципы реализации.
Динамический вектор остается динамическим вектором. Хэш-таблица -- хэш-таблицей, сбалансированное двоичное дерево -- сбалансированным двоичным деревом. Их свойства останутся при них вне зависимости о того, базе ООП реализуются эти понятия или на базе старого доброго структурного программирования.
На Си никто ж не будет реализовывать ООП без очень веских причин.
Для альтернативно одаренных повторю еще раз: вы сказали о неких накладных расходах в C++. Сказанное не мешало бы подтвердить хоть какими-то количественными показателями.
Вы упорно не можете. Вы упорно демонстрируете свою глупость. Если вам нравится публично позориться, то почему бы и не продолжить окунать вас в ваши же продукты.
Например, вектор векторов не образует в памяти регулярную структуру, такую как массив массивов
Вы настолько глупы, чтобы врать когда все ходы записаны?
PS. Если вы не поняли, а есть ощущение, что не поняли от слова совсем, то под утверждениями подразумевались в первую очередь вещи, вроде: "на реализацию ООП в C++ уходит гораздо больше оверхеда (по сравнению с С)"
Вопрос был про вектор, но вы не стали отвечать про вектор, вы откуда-то вытащили задачу про массив. Тогда как вектор -- это не массив. Вектор может использоваться для организации двумерного массива в виде вектора векторов, но к моему вопросу это отношения не имеет.
Если уж вы заговорили про массив на базе вектора векторов, то вот вам примитивная реализация элементарного примера на чистом Си, без ООП и инкапсуляции:
Попробуйте найти принципиальные отличия в ассемблерном коде, который компилятор сгенерировал для функции index_of_max_column.
И если уж вам так припекают накладные расходы на std::vector, то попробуйте изобразить его аналог на чистом Си на простых структурах и свободных функциях. А потом с помощью этой реализации сделайте нужную вам двумерную матрицу на базе вектора векторов. И расскажите читателям этого флейма куда же денется регулярная структура в памяти и все прочее. Ведь ни ООП, ни инкапсуляции в вашей реализации не будет, а результат окажется таким же.
Простите, но вашей глупости, выражающейся в афигительных формулировках, с меня достаточно. Ваша фраза -- "в реальной прикладной программе на C++ такой структуры matrix не будет" -- не содержит никаких ограничений, т.е. может трактоваться как "в любой реальной программе".
Так вот, не в любой. Отсюда и просьба к вам не говорить за всех, т.е. вводить ограничения в ваши высказывания. Чтобы можно было понять, что речь идет о "виденных вами лично" программах на C++, или о "написанных вами лично программах на C++", или о специально раскопанных вами на помойках фрагментах говнокода на C++, про который забыли даже его авторы.
Повторю вопрос специально для вас: "какие накладные расходы на ООП есть, например, у std::vector, у которого нет виртуальных методов, но есть инкапсуляция".
Вы бы еще за демонстрациями на говнокод.ру сходили бы. Единственный из показанных вами репозиториев, который имеет хотя бы нормальное количество звезд -- 99 на данный момент -- содержит просто лабы по программированию: "A simple mathematical matrix class written in C++ to be reused for future assignments in my Computational Linear Algebra class."
Да еще и с откровенной припиской: "The code almost definitely constains significant bugs and solves numerous problems in a naive, inefficient, and incomplete manner."
Именно потому, что в Си ООП нет, то накладные расходы на ООП в Си равны нулю.
Да, да, да. Поэтому когда в каком-нибудь Си-шном проекте, типа OpenSSL, потребуются аналоги виртуальных функций, которые колхозятся на структурах с указателями на функции, то это все абсолютно бесплатно. Ага.
Теперь же, когда выяснили, вы приведете какие-то цифры, подтверждающие ваше утверждение? Или после общих слов о том, что все тормозят одинаково в процентном отношении относительно всего остального (или что вы там имели в виду) никаких количественных оценок уже не предполагается?
А имел в виду, что, программируя на С++, мы будем вынуждены, в отличие от Си, использовать реализацию ООП, так как на ООП построены библиотеки С++ и практика программирования на С++.
Тут бы очень хотелось выяснить кто такие "мы".
А практика программирования на C++ уже давным-давно (лет 25 минимум, а то и все 30) держится на мультипарадигменности, где ООП соседствует как с обычным процедурным подходом, так и с обобщенным программированием.
Я писал, что накладные расходы C++ возникают именно из-за поддержки ООП
Уже несколько раз цитировал что именно вы написали, повторяться не буду. Просто еще раз напомню, что рассуждать о накладных расходах на что-то по сравнению с чем-то можно только в случае, если это "что-то" есть в том самом "чем-то". В Си ООП нет, поэтому оценивать накладные расходы C++ на ООП в сравнении с Си бессмысленно. Не удивительно, что фактически подтвердить свои утверждения вы не можете.
От вас были только общие слова и ссылки на репозитории со студенческим гонокодом.
Вы, кстати, сами читали статью, на которую ссылки дали? В частности раздел про инкапсуляцию, в которой копипаста из описания понятия "модуля" из модульного программирования.
А эти подтверждения сейчас здесь с нами, в этом обсуждении? А то примеры кода с ассемблерным выхлопом здесь приводили вовсе не вы.
Во-первых, посмотрите определение инкапсуляции хотя бы в 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++, про который забыли даже его авторы.
Нет, не ответили.
А теперь еще раз, может быть сейчас поймете: отучаемся говорить за всех.
Повторю вопрос специально для вас: "какие накладные расходы на ООП есть, например, у std::vector, у которого нет виртуальных методов, но есть инкапсуляция".
Ну расскажите, пожалуйста, какие накладные расходы на ООП есть, например, у std::vector, у которого нет виртуальных методов, но есть инкапсуляция.
Вы бы еще за демонстрациями на говнокод.ру сходили бы. Единственный из показанных вами репозиториев, который имеет хотя бы нормальное количество звезд -- 99 на данный момент -- содержит просто лабы по программированию: "A simple mathematical matrix class written in C++ to be reused for future assignments in my Computational Linear Algebra class."
Да еще и с откровенной припиской: "The code almost definitely constains significant bugs and solves numerous problems in a naive, inefficient, and incomplete manner."
Отучаемся говорить за всех (c)
И даже не в минутах.
Да, да, да. Поэтому когда в каком-нибудь Си-шном проекте, типа OpenSSL, потребуются аналоги виртуальных функций, которые колхозятся на структурах с указателями на функции, то это все абсолютно бесплатно. Ага.
Вот и приходится выяснять что же вы имели в виду.
Теперь же, когда выяснили, вы приведете какие-то цифры, подтверждающие ваше утверждение? Или после общих слов о том, что все тормозят одинаково в процентном отношении относительно всего остального (или что вы там имели в виду) никаких количественных оценок уже не предполагается?
Тут бы очень хотелось выяснить кто такие "мы".
А практика программирования на C++ уже давным-давно (лет 25 минимум, а то и все 30) держится на мультипарадигменности, где ООП соседствует как с обычным процедурным подходом, так и с обобщенным программированием.
Уже несколько раз цитировал что именно вы написали, повторяться не буду. Просто еще раз напомню, что рассуждать о накладных расходах на что-то по сравнению с чем-то можно только в случае, если это "что-то" есть в том самом "чем-то". В Си ООП нет, поэтому оценивать накладные расходы C++ на ООП в сравнении с Си бессмысленно. Не удивительно, что фактически подтвердить свои утверждения вы не можете.
Прекрасно, начиналось все с
а закончилось общими фразами
Да вы просто мастер аргументировать вами же высказанные утверждения.
Только вот тормозят C++ программы несколько не так, чем программы на Ruby, например.