Здравствуйте, Videoman, Вы писали:
V>90% случаев весь код выполняется на этапе компиляции и ничего не отнимает ни в плане скорости ни в плане размера программы.
Откуда оценка в 90%? Само собой, "чисто предикативные" шаблоны вроде is_arithmetic или is_same именно так и работают, но и они выполняются компилятором в десятки-сотни раз медленнее, чем соответствующие предикаты, будь они встроены в компилятор. А используются эти предикаты массово, в том числе во вложенных/рекурсивных шаблонах, и в итоге неслабо тормозят компиляцию.
Чтобы шаблонный код на 90% (или хотя бы на 50%) выполнялся на этапе компиляции, программист должен хорошо понимать, во что развернется та или иная шаблонная конструкция. Поскольку шаблоны в C++ традиционно используются "не благодаря, а вопреки", большинство программистов не в состоянии адекватно понять, как работают все костыли, на которых реализованы даже шаблоны из std. Но в случае непосредственного использования шаблонов из std хоть можно доверять их авторам, которые в этой кухне неплохо разбираются — там оверхед действительно небольшой. Но когда нужно модифицировать стандартный шаблон или сделать свой на похожих принципах, из-за того же непонимания механизма лепятся конструкции "лишь бы заработало". Как только заработало — задача считается решенной, даже если вызов разворачивается в "ужас-ужас", но кто смотрит, во что оно развернулось? Кстати, есть компиляторы, умеющие показать результат раскрутки шаблона в терминах языка, а не ассемблерного кода?
V>Непринятие "чистыми" С программистами шаблонов С++ основывается на их профессиональной привычке, что много кода — медленно, большой объем программы.
Лично я очень люблю шаблоны C++ в их изначальной ипостаси, как средство параметризации. Но меня тошнит от подхода "если это может быть сделано на шаблонах — давайте сделаем на шаблонах". А поскольку на шаблонах, как известно, можно сделать практически все, то большинство идей по расширению C++ выливается в добавление новых шаблонов в std.
И ладно, если бы такой подход хоть сопровождался поддержкой "метапрограммирования с человеческим лицом".
Какие в языке есть средства отладочного слежения за тем, как раскручивается шаблон? Никаких. Какие есть средства диагностики ошибок, чтобы выдать пользователю шаблона осмысленное сообщение, а не вываливать потроха с кучей вспомогательных типов, классов и переменных? Опять никаких. Бассейн построили тридцать лет назад, а воду в него никак не нальют.
Да, и я уже лет двадцать пять, как не "С-программист".
То же самое ООП на чистом C выглядит ничуть не лучше современного метапрограммирования на C++.
V>Я вполне согласен что системщикам не нравится неявные вызовы new/delete или исключения, тем более в ядре, где невозможно явно контролировать реализацию.
С new/delete как раз все просто — достаточно их переопределить (я так и делаю). С исключениями хуже: даже если какой-то модуль их только бросает, но нигде не обрабатывает, в языке нет законного способа определить свою функцию вместо стандартного обработчика, которая вызывалась бы в точке выброса исключения. В каждой реализации для этого нужны свои костыли.
По-хорошему, такие вещи тоже нужно документировать в стандарте, хотя бы в виде рекомендаций, чтобы в реализациях CRT не городили кто во что горазд.
V>Зато в современном С++ появилась масса вещей которые можно делать прямо во время компиляции и с помощью которых можно автоматизировать написание большого объема почти одинакового кода
Так они почти все появились не в C++, а в его std, на тех самых шаблонах. Это как если бы расширения фортрана делались главным образом через подпрограммы/функции на том же фортране.
V>Чем, например системному программисту может навредить RAII?
Ничем, оно давно и активно используется и в ядерном, и в микроконтроллерном коде. Само-то по себе оно ни ресурсов лишних не требует, ни на CRT не завязано. Подобные вещи в C++ я очень люблю.
V>Чем вам помешают STL-ные: array, string_view, optional, variant ?
Прежде всего тем, что при любой ошибке их использования компилятор, вместо осмысленного сообщения, вываливает мне потроха шаблона, и я вынужден на них смотреть, хотя совершенно этого не хочу.
V>Чем плох constexr ?
Ничем. Чисто языковые расширения я всегда приветствую, и хотел бы иметь побольше средств контроля правильности программы, но их почему-то внедряют в последнюю очередь.
ЕМ>>Тем, что она давно подмяла язык под себя, предложив извращенную реализацию того, что должно быть нормально реализовано в компиляторе. По уму, ее давно нужно было выделить в отдельный стандарт и разбить на уровни, реализация которых опциональна.
V>Но зато, часто на практике, по самой задаче просто нужно написать много "шаблонного" кода. Обычно это какие-то табличные вещи, таблицы маршрутизации, какие-то множества структур. Тут С не может дать ничего в помощь разработчику.
А что может дать C++ для удобного представления исходных таблиц в коде программы? Обрабатывать-то их и на чистом C не особо сложно.
