Здравствуйте, karbofos42, Вы писали:
П>>А сейчас что мешает написать общий код?
K>Что это нужно делать задом-наперёд,
Что значит: "задом наперёд"?
K>многословно
Да не особенно
K>и в итоге я уверен, что большинство этим не занимается, ибо это так "удобно".
Как не надо — не занимается, когда надо — занимается. Есть конечно, некоторое количество сишечников, которые пишут на на C на С++. Есть некоторое количество неосиливших. Люди разные.
П>>В текущей ситуации вызов size'а будет только один, если контейнер не меняется в ходе работы. В случае виртуального size оптимизатор скорее всего не сможет доказать, что size всегда возвращает одно и то же, и будет честно дёрuать виртуальный size на каждой итерации
K>Интересный оптимизатор. Определять неизменность состояния объекта умеет, а что у объекта тип внезапно не поменялся — нет.
Определять, что у объекта тип не поменялся — он умеет, он не умеет заглядывать в объектный код, в котором лежит реализация виртуального метода, и определять, что size не поменялся.
П>>Нормально выглядит. Я не понимаю, что ты докопался до плюсов? Иди в шарповый форум, раз на шарпе пишешь, не надо предлагать переделать плюсики в шарп
K>Я не предлагаю ничего менять. Наглядно показываю как в плюсах ради экономии на тех же виртуальных вызовах пишут задом-наперёд и радуются.
Что значит: "задом наперёд"?
Да, ради экономии. Если все методы будут виртуальными, это будет заметно снижать производительность
Здравствуйте, karbofos42, Вы писали:
П>>Мне коллекции C++ за счет одинаковых интерфейсов тоже видятся удобными.
K>Так у них нет одинаковых интерфейсов.
Есть конечно, просто это сделано не так, как ты привык, не через таблицу виртуальных методов
K>Есть частичное совпадение, благодаря которому работает утиная типизация и можно навертеть шаблоны.
Всё тоже самое, что и у вас, только у нас в компайл тайме, а у вас в рантайме.
K>В своих классах тоже используете не наследование и виртуальные методы, а просто одинаково называете их и потом через шаблоны вызываете?
Когда как. Если вся информация доступна в компайл-тайме — то конечно, никаких виртуальных методов. Иначе можно и виртуальные методы использовать. Не вижу проблем. У нас и так и так можно, у вас — только в рантайме.
П>>Не вижу проблем. Более того, такое не слишком нужно. Ну не могут алгоритмы одинаково хорошо работать со всеми типами контейнеров. У каждого контейнера свои преимущества и недостатки, и их надо выбирать, исходя из решаемых задач. А у вас, как я понимаю, дерьмово выходит с любыми контейнерами. Зато — удобно.
K>У меня то нормально всё получается. И когда кто-то выбирает неправильный контейнер или использование уже существующего меняется, то без проблем меняю тип контейнера и это не приводит к лавинообразным изменениям.
Это если интерфейсы контейнеров совпадают, и прокатывает утиная типизация
K>Ну, вот в жизни пишется как мне тут в теме несколько примеров с шаблонами привели? K>Или всё же чаще хардкодится конкретный условный std::vector и методы все его принимают, т.к. нафиг надо шаблоны городить?
Здравствуйте, пффф, Вы писали:
П>Что значит: "задом наперёд"?
Вместо того, чтобы просто написать: коллекция.добавить(10), нужно сначала подготовить вставлятор в эту коллекцию, потом сообщить ему, что нужно добавить 10, чтобы он уже добавил элемент в коллекцию.
П>Определять, что у объекта тип не поменялся — он умеет, он не умеет заглядывать в объектный код, в котором лежит реализация виртуального метода, и определять, что size не поменялся.
можно ему подсказать, записав значение в локальную переменную и обращаясь к ней, а не дёргая постоянно виртуальный метод.
П>И?
"виртуальные функции сильно снижают быстродействие"
Здравствуйте, пффф, Вы писали:
П>Всё тоже самое, что и у вас, только у нас в компайл тайме, а у вас в рантайме.
Тут в соседней ветке ваш компайл тайм уже выстрелил тем, что молча int сложил в коллекции float и bool.
В C# я на этапе компиляции узнаю, что нужен ICollection<int>, а не ICollection<bool>
П>Когда как. Если вся информация доступна в компайл-тайме — то конечно, никаких виртуальных методов. Иначе можно и виртуальные методы использовать. Не вижу проблем. У нас и так и так можно, у вас — только в рантайме.
Да как-то я в компайл тайме большинство проблем узнаю
П>Это если интерфейсы контейнеров совпадают, и прокатывает утиная типизация
Так это в C++, а в C# все коллекции реализуют ICollection<T> или хотя бы IEnumerable<T> и типы контролируются штатно на этапе компиляции, не нужно ничего на шаблонах городить.
Здравствуйте, karbofos42, Вы писали:
K>Тут в соседней ветке ваш компайл тайм уже выстрелил тем, что молча int сложил в коллекции float и bool.
Все в рамках правил языка. Что просили у компилятора, то он вам и сделал.
K>В C# я на этапе компиляции узнаю, что нужен ICollection<int>, а не ICollection<bool>
Зато у вас негров линчуют вы не сможете своей функции process, которая оперирует только ICollection, дать указание выводить значения на консоль, вместо сохранения в контейнер. Ну или же вам придется делать реализацию ICollection для этих целей.
Да и вообще предмет сопоставления Java/C# с C++ непонятен. Ниши этих языков разошлись давным-давно. Если у вас нет необходимости использовать C++ и делать все на C#, то какая разница как сделано в C++. Если же нужно все-таки пользоваться C++, то без разницы как сделано в C#.
Здесь свой монастырь, свой устав. Поменять вы его все равно не сможете.
Здравствуйте, Евгений Музыченко, Вы писали:
П>>те, кто под них пишет — конченные люди, их уже только могила исправит. И пишут они лютое говно.
ЕМ>Вот прям все, без исключения? А почему, собственно? Что, по-Вашему, делает их такими?
Отсутствие опыта решения сложных задач делает их такими
П>>Я знавал одного сишника/асмщика с PIC — на его код без слез смотреть было нельзя. Под MSC-51 сам писал. И много читал сишного кода. Тоже тоже очень хотелось плакать. Всё это было написано людьми, явно далекими от программирования, и ни о какой эффективности там говорить не приходилось.
ЕМ>А я видел немало кода, написанного вроде бы профессиональными программистами, но тоже хотелось плакать. Какой вывод-то?
Вывод такой, что ваше утверждение про сильных сишников, выходцев из среды разработки под уродцев, высосано из пальца
П>>Ни о каком промышленном серьёзном применении этого говна речи идти не может.
ЕМ>"Промышленное серьезное применение" — это не только сложные станки, выпускаемые сотнями-тысячами штук. Это любая индустрия с достаточно большими капиталовложениями и объемами производства.
Мы вообще-то обсуждали сложность решаемых МК задач, и вы утверждали, что на 8ми-битниках ух какие сложные задачи решаются, и это закаляет 8ми-битных программистов.
ЕМ>Именно из-за устройства МК? Какие параметры МК обрекают любой код для него на говнистость?
Убогость и огранниченность возможностей -> невозможность решать сложные задачи -> никто не будет для дверного звонка нанимать дорогих профессиональных программистов -> прошивку пишет местный инженер, краем глаза когда-то видевший сишечку.
П>>Это нельзя называть серьёзным промышленным применением, ничего сложного там и не делается.
ЕМ>А если этого выпускается тонны, и продается на миллиарды?
Неважно, сколько миллиардов тонн МК выплавляет индустрия, важно, что на этих МК не решаются сложные задачи. Я про контекст нашего спора, о котором вы начали забывать
П>>лучше бы, чтобы все уже выкинули это древнее говнецо на помоечку, и вкорячивали бы STMку какую, туда бы прошивали Lua, и для кастомизации нанимали бы студента-хипстера
ЕМ>Да, и в каждые настольные часы вкорячить линукс. А кто за все это заплатит? STM-ки вроде как не бесплатные.
В настольных часах нет задач для STM-ки. Прошивку напишет любой инженер за месяц, а средний плюсовик — за полдня.
П>>Другое применение этих уродцев — это контроллеры стиральных машин
ЕМ>Которые выпускаются штучно, отчего встречаются очень редко.
В в стиральных машинах нет задач для STM-ки. Прошивку напишет любой инженер за месяц, а средний плюсовик — за полдня.
П>>где оно решает мега сложные задачи по измерению температуры воды и её нагреву (там аж ПИД-регулятор надо делать, это да), да по смене режимов работы, включения мотора барабана и насосов на двухчасовом цикле стирки. Да, тут 5 Мгц частоты точно мало, тут 160 надо.
ЕМ>Про оценку распределения масс в барабане по соотношению токов в обмотках двигателя Вы явно не в курсе.
Покажите мне прошивку стиральной машины, где этим заморочились
П>>Ещё применение — выполнять какую-то примитивнейшую функцию, потребляя как можно меньше энергии. Не спорю, полезно иногда
ЕМ>Вот прям иногда? Если каждые часы, термометр, датчик дыма и прочая мелочь вокруг Вас станет разряжать свой источник не за год-два, а за две недели, Вы ничуть не расстроитесь?
Да, это иногда. И да, для всех этих устройств не нужна STM-ка, и да, прошивку для таких устройств пишет любой инженер за месяц, а средний плюсовик — за полдня.
П>>но квалификации тут не нужно никакой от слова вообще.
ЕМ>Изначально речь шла не о квалификации, а о возможности применения для всего этого более удобного и надежного языка, нежели ассемблер или C. Глядишь, и говнокода стало бы поменьше.
Изначально речь шла о том, что из этой среды вырастают крутые сишечники, которые рвут среднего программиста на плюсах, как тузик.
П>>прошивки к этим устройствам пишут не какие-то супер-эффективные сишники-программисты, прошивки к ним пишут инженеры-электронщики
ЕМ>Возможно, Вы не в курсе, но многие сильные программисты вышли из технарей, изучая программирование самостоятельно. А вот изначально подготовленные на профильных факультетах далеко не всегда демонстрируют хороший уровень.
Ещё больше вышло из получивших профильное образование
П>>Петров, у вас же в институте язык C давали? — Давали, один семестр. — Отлично, Петров, вот ты прошивку и напишешь".
ЕМ>И что, если бы Петрову давали не C, а C++ или Pascal, он написал бы хуже?
Точно такое говно бы написал, потому что язык он видел давно и краем глаза
П>>А вы много вообще сишников знаете, и ещё и пишущих под контроллеры? Нету таких сишников, как класса.
ЕМ>Когда мне попадаются исходники прошивок для устройств, которые я использую, многие производят неплохое впечатление.
Исходники в студию.
П>>У плюсового компилятора гораздо больше информации, которую можно использовать для оптимизации. И плюсовый компилятор умеет многое делать на этапе компиляции, на сишечке это всё будет в рантайме.
ЕМ>Каким образом все эти качества могут концентрироваться в плюсовом компиляторе, но избегать попадания в сишный? Если в компиляторе есть соответствующая логика — он будет оптимизировать до упора, если ее нет — будет делать код, как придется. Стандарты C++ не устанавливают конкретных требований к оптимизации, за исключением некоторых явно оговоренных. А многие компиляторы изначально умеют и C, и C++. Функционально эквивалентные исходники они чаще всего компилируют в один и тот же код.
В плюсах библиотеки в основном хидер-онли, и вот практически буквально всё доступно компилятору для анализа. В сишечке в хидерах только описания структур и прототипы функций, остальное лежит в объектниках.
ЕМ>>>Просто писать будет удобнее, код будет более читаемым, ошибки делать сложнее, а вылавливать — легче.
П>>Это вы про сишечку?
ЕМ>Это я про плюсики по сравнению с сишечкой.
Что-то я тут уже нить потерял. Вы о чем?
П>>Я, как минимум, написал один HTTP-сервер на сишечке
ЕМ>Это считается сложным проектом для C? Не знал, честно. Вот, например, Simple HTTP Server — цельных 25 килобайт исходник. Или Ваш был сильно круче?
Да, мой был сильно круче, потому что не просто раздавал файлы с диска, а был приложением по настройке девайса, и генерил контент и обрабатывал пользовательский ввод, там было что-то недо-CMS
П>>что написали на сишечке вы?
ЕМ>Успел написать пару драйверов средней сложности, несколько приложений для работы со звуком, кучку разных мелких утилит. Делал оконную подсистему и музыкальный секвенсор, но бросил.
Бросили, на сишечке тяжело тащить стало?
ЕМ>Можем помериться приборами по ассемблерам. Я на одном ассемблере когда-то написал многопользовательскую интерактивную систему составления программ для графопостроителя и управления заданиями для него (это когда в школе учился), а на другом — программу составления и печати спецификаций оборудования для газодобывающей промышленности, по набору заданных шаблонов (эту спихнул в качестве дипломной работы в институте, чтоб отдельной темы не брать). А в машинных кодах (ибо на той машине ассемблера не было) я написал дизассемблер (чтоб удобнее было возиться с кодами) и визуальный текстовый редактор с форматированием и печатью в несколько столбцов. И не скажу, что это были сложные задачи — вполне себе ординарные.
Они сложные только для пишущего на асме или на сишечке — объем работы достаточно велик.
П>>Я могу примерно прикинуть мою производительность на масме, и на плюсиках. Субъективно разница где-то от 1000 до 10000 раз
ЕМ>Как-то слишком разительно.
С чего бы? Я на плюсах напишу один раз обобщенный код, а на асме буду писать макросы, а потом всё это каждый раз отлаживать
ЕМ>Ну, или для Вас ассемблеры просто сильно непривычны.
Да, x86 я на масме немного трогал, но быстро соскочил на сишечку, а потом на плюсики, в основном опыт был на Z80.
П>>Код среднего плюсовика всегда выиграет у кода среднего сишечника по скорости.
ЕМ>Да не выиграет он всегда. Если и тот, и другой делают код согласно устоявшимся правилам и рекомендациям, то где-то будет быстрее на C за счет простоты, где-то — на плюсах за счет выразительности. А если как попало, то и там, и там будет медленно.
Не очень понятно, почему на сишечке будет быстрее за счёт простоты? На плюсах обязательно писать сложно, если напишешь просто, коллеги засмеют, так что ли?
Плюсовый код будет быстрее за счёт возможностей компилятора по оптимизации.
Здравствуйте, karbofos42, Вы писали:
П>>Что значит: "задом наперёд"?
K>Вместо того, чтобы просто написать: коллекция.добавить(10), нужно сначала подготовить вставлятор в эту коллекцию, потом сообщить ему, что нужно добавить 10, чтобы он уже добавил элемент в коллекцию.
можно просто написать: коллекция.push_back(10)
П>>Определять, что у объекта тип не поменялся — он умеет, он не умеет заглядывать в объектный код, в котором лежит реализация виртуального метода, и определять, что size не поменялся.
K>можно ему подсказать, записав значение в локальную переменную и обращаясь к ней, а не дёргая постоянно виртуальный метод.
Ага, всю работу по оптимизации делать за компилятор. Вот так вот в реальной жизни и будет — плюсовый код будет всегда простым и элегантным, а ваш обрастёт подсказками и превратится в кучу неподдерживаемого кала
П>>И?
K>"виртуальные функции сильно снижают быстродействие"
Здравствуйте, karbofos42, Вы писали:
П>>Всё тоже самое, что и у вас, только у нас в компайл тайме, а у вас в рантайме.
K>Тут в соседней ветке ваш компайл тайм уже выстрелил тем, что молча int сложил в коллекции float и bool.
Ну если ты все варниги отключил, то ты сам себе буратино
K>В C# я на этапе компиляции узнаю, что нужен ICollection<int>, а не ICollection<bool>
В плюсах я тоже узнаю, если не буду игнорировать предупреждения
П>>Когда как. Если вся информация доступна в компайл-тайме — то конечно, никаких виртуальных методов. Иначе можно и виртуальные методы использовать. Не вижу проблем. У нас и так и так можно, у вас — только в рантайме.
K>Да как-то я в компайл тайме большинство проблем узнаю
Ну, я рад за тебя
П>>Это если интерфейсы контейнеров совпадают, и прокатывает утиная типизация
K>Так это в C++, а в C# все коллекции реализуют ICollection<T> или хотя бы IEnumerable<T> и типы контролируются штатно на этапе компиляции, не нужно ничего на шаблонах городить.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это считается сложным проектом для C? Не знал, честно. Вот, например, Simple HTTP Server — цельных 25 килобайт исходник.
А вы в код заглядывали? Что там комментарии типа "IMPLEMENT ME" делают?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если объектов единицы-десятки миллионов, и в каждом до десятков байт, то можно обойтись и 32-разрядными адресами, это будет по четыре байта. Если в объекте сорок байт, то четыре байта — 10%. Это считается много?
Не очень понял, откуда вдруг 4 байта возникли, если их 8. Делать 32-х разрядные приложения?
N>>Восемь лишних байт на класс в каждом экземпляре.
ЕМ>Если объектов единицы-десятки миллионов, и в каждом до десятков байт, то можно обойтись и 32-разрядными адресами, это будет по четыре байта. Если в объекте сорок байт, то четыре байта — 10%. Это считается много?
Вроде, у создателей Excel была проблема, когда каждая ячейка была ком объектом, памяти жрало как не в себя. Сейчас конечно память не ресурс, жри не хочу
Здравствуйте, T4r4sB, Вы писали:
K>>Вместо прямого обращения к коллекции идёт прослойка в виде итератора, который и создать нужно и его методы дёрнуть.
TB>Жесть
Человек пишет на шарпе, чего с него взять. Чего он на этот форум вообще забрел
Здравствуйте, karbofos42, Вы писали:
BFE>>Ну так возьмите vector и пользуйте.
K>Потом все вызовы придётся переписывать, если захочется поменять вектор на множество или какой другой контейнер.
Вектор и множество — принципиально разные типы контейнеров. Если вам захотелось поменять один на другой, это повод хорошенько задуматься
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот рабочий сервер в 200 строк на C.
ЕМ>Вот однопоточный и многопоточный серверы, где-то на 100 кб исходников.
Евгений, вам на подумать: один из самых активно используемых и проверенных в продакшене парсеров HTTP протокола, llhttp, имеет реализацию ~300Kb. Причем, как я понял, авторы сделали это посредством генерации кода из TypeScript-а, т.к. писать надежно на чистом Си -- это убиться можно.
И если вы находите какое-то говно в 200 строк, то это всего лишь означает до нормальной поддержки HTTP там как до Луны.
Здравствуйте, so5team, Вы писали:
S>Все в рамках правил языка. Что просили у компилятора, то он вам и сделал.
Так себе компайл тайм, который якобы все ошибки показывает.
В С++ вроде и по максимуму на этапе компиляции всё высчитывается и контролируется, но зато язык столько всего позволяет, что потенциально пропускается куча глупых "опечаток".
S>Зато у вас негров линчуют вы не сможете своей process, которая оперирует только ICollection, дать указание выводить значения на консоль, вместо сохранения в контейнер. Ну или же вам придется делать реализацию ICollection для этих целей.
Ни разу как-то в жизни не сталкивался с необходимостью работать с консолью как с контейнером.
Если нужен универсальный метод, который сможет и в консоль писать, то можно написать что-то типа:
public void Process(IEnumerable<int> items, Action<int> target1, Action<int> target2)
{
foreach (var value in items)
{
if (value % 2 == 0) { target1(value); }
else { target2(value); }
}
}
...
ICollection<int> list = new List<int>();
ICollection<int> set = new HashSet<int>();
Process(new int[] {1, 2, 3, 4, 5}, list.Add, set.Add);
Process(new int[] {1, 2, 3, 4, 5}, Console.WriteLine, (v) => Console.WriteLine($"_{v}"));
уже ближе к C++ по упоротости получается )
S>Да и вообще предмет сопоставления Java/C# с C++ непонятен. Ниши этих языков разошлись давным-давно. Если у вас нет необходимости использовать C++ и делать все на C#, то какая разница как сделано в C++. Если же нужно все-таки пользоваться C++, то без разницы как сделано в C#.
Java и C# тут сугубо как пример как можно было сделать контейнеры с виртуальными методами, а не сопоставление что лучше или хуже.
Есть STL, которую вероятно писали не дураки и по какой-то причине от виртуализации там по-моему совсем отказались.
На мой взгляд коллекции и их интерфейсы в C#/Java удобнее в 99% случаев, т.к. в большинстве своём выполняются типовые операции перебора, добавления, поиска.
В STL это типовое всё либо прибивается к конкретному типу коллекции и дальше её сложнее поменять, если понадобится.
Либо там придётся больше писать и до кучи получишь меньше контроля за типами объектов.
Пример этот не взлетел, т.к. пошли разговоры о том, что это в Java/C# неудобные и неправильные коллекции, унифицированный Add не нужон и не понятен, а в STL всё сделано лучше.
Если бы взлетел, можно было достаточно простой бенчмарк изобразить со сравнением STL контейнеров и аналогов с реализацией общих интерфейсов Iterable и Collection как в Java, например.
S>Так в чем смысл?
Любой в этой теме может привести свой пример, на котором наглядно можно продемонстрировать насколько виртуальные методы в реальности дёшевы в использовании или же наоборот это дорогостоящая вещь, которую имеет смысл обходить стороной как это сделали в STL. У меня очевидно не получилось с примером
Здравствуйте, пффф, Вы писали:
П>можно просто написать: коллекция.push_back(10)
std::set это не одобрит
П>Ага, всю работу по оптимизации делать за компилятор. Вот так вот в реальной жизни и будет — плюсовый код будет всегда простым и элегантным, а ваш обрастёт подсказками и превратится в кучу неподдерживаемого кала
Я хохотался с простого и элегантного плюсового кода
Здравствуйте, пффф, Вы писали:
П>Вектор и множество — принципиально разные типы контейнеров. Если вам захотелось поменять один на другой, это повод хорошенько задуматься
Так я задумался и увидел, что в нужной функции просадку даёт поиск элементов в векторе, т.к. идёт перебором.
Хотелось бы как-то легко и просто оценить поведение на этих данных множеств. Может они памяти слишком много выжрут и не подойдут или просядут в других функциях.
А то будешь сидеть пол дня менять вектор на множество, результат не понравится и в итоге оставишь вектор, просто элементы отсортируешь и перебор на бинарный поиск заменишь, чтобы хоть немного быстрее работало.
Но конечно плюсовики все сразу при чтении задачи знают с уверенностью в 100% какой контейнер использовать, суровые реалии не меняются и таких задач не встаёт.
А если и встают, то все точно знают сколько выигрыша даст другой контейнер, а где сколько проиграет текущему.
Здравствуйте, karbofos42, Вы писали:
S>>Все в рамках правил языка. Что просили у компилятора, то он вам и сделал.
K>Так себе компайл тайм, который якобы все ошибки показывает.
Вынужден повторить: неявное приведение от int к bool или к float -- это не ошибка с точки зрения языка. Это легальная операция.
K>В С++ вроде и по максимуму на этапе компиляции всё высчитывается и контролируется, но зато язык столько всего позволяет, что потенциально пропускается куча глупых "опечаток".
Да, C++ печально известен этим качеством.
Благо, сейчас не желающие иметь дело с C++ имеют просто шикарный выбор альтернатив: Java/Scala/Kotlin, C#/F#, Go, Rust.
Тем же, кто по каким-то причинам остаются в C++, живут в соответствии с правилами C++.
K>Ни разу как-то в жизни не сталкивался с необходимостью работать с консолью как с контейнером.
Мне, например, сложно вспомнить когда в последний раз приходилось менять vector на set. Тем не менее, этот момент мы обсуждаем.
K>Если нужен универсальный метод, который сможет и в консоль писать, то можно написать что-то типа: K>
И получилось, что ICollection пошли лесом.
S>>Да и вообще предмет сопоставления Java/C# с C++ непонятен. Ниши этих языков разошлись давным-давно. Если у вас нет необходимости использовать C++ и делать все на C#, то какая разница как сделано в C++. Если же нужно все-таки пользоваться C++, то без разницы как сделано в C#.
K>Java и C# тут сугубо как пример как можно было сделать контейнеры с виртуальными методами, а не сопоставление что лучше или хуже.
Ну OK. Все равно не понятен выхлоп от такого сравнения.
K>Есть STL, которую вероятно писали не дураки и по какой-то причине от виртуализации там по-моему совсем отказались.
Потому что виртуальные вызовы не бесплатны. Даже если они добавляют 1.5% просадки производительности, то для мира C++ это все равно может оказаться непозволительно дорого.
K>На мой взгляд коллекции и их интерфейсы в C#/Java удобнее в 99% случаев, т.к. в большинстве своём выполняются типовые операции перебора, добавления, поиска.
И это замечательно.
Даже в С++ в итоге добавили ranges, т.к. пара [begin, end) местами, неудобна для использования. Так что гибкость итераторов имеет свою цену.
K>В STL это типовое всё либо прибивается к конкретному типу коллекции и дальше её сложнее поменять, если понадобится.
Зато получаем максимальную эффективность. Таков путь (c)
K>Либо там придётся больше писать и до кучи получишь меньше контроля за типами объектов.
Зависит от того, как писать.
S>>Так в чем смысл?
K>Любой в этой теме может привести свой пример, на котором наглядно можно продемонстрировать насколько виртуальные методы в реальности дёшевы в использовании или же наоборот это дорогостоящая вещь, которую имеет смысл обходить стороной как это сделали в STL.
Так хороший пример стоит некоторых трудозатрат. По-моему, ежу понятно, что если сравнивать виртуальные и прямые вызовы, без какой-либо полезной нагрузки, то виртуальные будут дороже. Интересно то, насколько в реальности обходятся виртуальные вызовы, когда и полезная нагрузка -- это не одно умножение или один инкремент, и какая-то форма полиморфизма критически нужна.
Вряд ли кто-то такое может опубликовать из своей профессиональной деятельности.
А готовить голый пример (вот то же перемножение матриц, которое как раз должно дать миллионы (если не миллиарды) вызовов в секунду) -- это же не менее часа работы на пару реализаций, их тестирование, бенчмаркинг, оформление результатов сюда в форум... Уж лучше я потрачу этот час на то, что мне реальные деньги принесет.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>задачу создания таблиц строк вида "длина+текст" это все равно не решает, приходится извращаться, как и раньше. BFE>>А string_view на что? ЕМ>Так все равно ж исходные литералы лежат отдельно, с нулями в конце, а рядом лежат ссылки на них в объектах string_view.
В рамках языка C++ нет смысла делать что-то большее.
А почему, собственно? Что, по-Вашему, делает их такими? 
