Здравствуйте, Евгений Музыченко, Вы писали:
RW>>Даже Ada отдыхает со своими 1186 листиков
ЕМ>Меня последние годы не покидает стойкое сомнение в психической адекватности этих людей. Уже давно понятно, что C++ превратился в уродливого монстра, даже полное изучение и использование которого требует непомерных затрат, не говоря уже о реализации и поддержке, но они упорно двигают его все дальше и дальше.
Не нравится — не пользуйся. По мне так — пользоваться просто, и целиком всё знать необязательно
ЗЫ И да, мне нравится, что язык стал активно развиваться, и то, что код написанный 20 лет назад собирается и работает точно так же, как и раньше
Здравствуйте, Евгений Музыченко, Вы писали:
R>>вам кто-то зажал пальцы в дверь и заставляет использовать С++ что ли?
ЕМ>В целом-то я его люблю, но лишь в части более-менее адекватной реализации.
Так и пользуйся тем, что нравится. Никто же не заставляет прям всем пользоваться
Здравствуйте, Евгений Музыченко, Вы писали:
KP>>А когда он не менялся, со всех сторон было "язык умер! желанную фичу не добавляют! как можно пользоваться языком застрявшим в 90-х!".
ЕМ>Так и надо было развивать язык в рамках подхода, обеспечившего успех и C, и C++ — всю работу выполняют функции, а встроенные средства языка лишь определяют сущности и операции над ними. При таком подходе на языке можно с одинаковым удобством и эффективностью писать программы для простейших микроконтроллеров, ядра ОС, драйверы, мелкие программы и навороченные комплексы. В этом была уникальность языка и основная причина его популярности.
Я под STM32 на 11ом пишу, есть люди, которые на шаблонах C++ 17го стандарта с constexpr'ами фигачат. И, кстати, орчень эффективно выходит, по сравнению с более ранними стандартами
ЕМ>А потом среди поклонников (и разработчиков стандарта) возобладал традиционный подход к ЯП — "чтобы реализовать такой-то алгоритм, нужно написать вот это и вот это". Подавляющее большинство C++-программистов уже давно не понимает, что у программы внутри, как она взаимодействует со средой выполнения, какие конструкции порождают компактный код, а какие — развесистый, не умеет оптимизировать без профайлера и т.п., а просто кодирует алгоритм мало-мальски подходящими конструкциями языка и стандартной библиотеки, которая тоже превратилась в паровоз, нахлобученный на легковушку. Для всего этого уже было 100500 самых разных языков, и регулярно появляются новые, какой был смысл тащить туда еще и C++?
Куча непонятных заявлений. На других языках что, лучше понимают, что "у программы внутри"? Лучше без профайлера понимают, как писать эффективно?
"просто кодирует алгоритм мало-мальски подходящими конструкциями языка и стандартной библиотеки" — вообще-то этим занимаются большинство программистов всегда, а на других языках — так вообще это число ассимтотически приближается к 100%
Чем тебе стандартная библиотека, и её развитие, не нравится — тоже не понятно.
Здравствуйте, Marty, Вы писали:
M>Я под STM32 на 11ом пишу, есть люди, которые на шаблонах C++ 17го стандарта с constexpr'ами фигачат. И, кстати, орчень эффективно выходит, по сравнению с более ранними стандартами
Вряд ли дело в стандартах — скорее всего, просто оптимизаторы стали лучше работать.
M>На других языках что, лучше понимают, что "у программы внутри"? Лучше без профайлера понимают, как писать эффективно?
У большинства других языков это попросту не входит в парадигму. Уникальность C — в том, что в нем принципиально нет языковых конструкций, могущих породить объемный и/или тормозной код. C++ это унаследовал, и единственной чисто языковой фичей, которая могла дать избыточный код или тормоза, были исключения. Но их и невозможно было реализовать иначе, поэтому к ним нет претензий.
А вот когда вдруг обнаружилось, что на шаблонах можно делать то, что в других условиях обязан делать сам язык — получение сведений о типах/объектах, их взаимосвязях и прочие compile-time сервисы — и этот подход был признан правильным, тогда и началась вакханалия. Большинство ведь толком не понимает, как работает шаблонная рекурсия, завязанная на SFINAE, поэтому тупо копирует рекомендованные конструкции из учебников; если после этого вылезают странные ошибки — жалуются в форумах, где им советуют "поправить вот здесь вот так". А привыкнув к такому подходу, начинает столь же бездумно лепить шаблонные конструкции для организации/обработки данных. И вместо прозрачного языка с контролируемым объемом и быстродействием программы получается еще один "язык выражения намерений программиста", которых и без того множество.
M>Чем тебе стандартная библиотека, и её развитие, не нравится — тоже не понятно.
Тем, что она давно подмяла язык под себя, предложив извращенную реализацию того, что должно быть нормально реализовано в компиляторе. По уму, ее давно нужно было выделить в отдельный стандарт и разбить на уровни, реализация которых опциональна.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А привыкнув к такому подходу, начинает столь же бездумно лепить шаблонные конструкции для организации/обработки данных.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Большинство ведь толком не понимает, как работает шаблонная рекурсия, завязанная на SFINAE, поэтому тупо копирует рекомендованные конструкции из учебников; если после этого вылезают странные ошибки — жалуются в форумах, где им советуют "поправить вот здесь вот так". А привыкнув к такому подходу, начинает столь же бездумно лепить шаблонные конструкции для организации/обработки данных. И вместо прозрачного языка с контролируемым объемом и быстродействием программы получается еще один "язык выражения намерений программиста", которых и без того множество.
Просто интересно стало, на чем основаны эти утверждения про большинство. Как ты статистику собирал?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Я под STM32 на 11ом пишу, есть люди, которые на шаблонах C++ 17го стандарта с constexpr'ами фигачат. И, кстати, орчень эффективно выходит, по сравнению с более ранними стандартами
ЕМ>Вряд ли дело в стандартах — скорее всего, просто оптимизаторы стали лучше работать.
Из-за constexpr'а, да
M>>На других языках что, лучше понимают, что "у программы внутри"? Лучше без профайлера понимают, как писать эффективно?
ЕМ>У большинства других языков это попросту не входит в парадигму. Уникальность C — в том, что в нем принципиально нет языковых конструкций, могущих породить объемный и/или тормозной код. C++ это унаследовал, и единственной чисто языковой фичей, которая могла дать избыточный код или тормоза, были исключения. Но их и невозможно было реализовать иначе, поэтому к ним нет претензий.
И в чем проблема?
ЕМ>А вот когда вдруг обнаружилось, что на шаблонах можно делать то, что в других условиях обязан делать сам язык — получение сведений о типах/объектах, их взаимосвязях и прочие compile-time сервисы — и этот подход был признан правильным, тогда и началась вакханалия. Большинство ведь толком не понимает, как работает шаблонная рекурсия, завязанная на SFINAE, поэтому тупо копирует рекомендованные конструкции из учебников; если после этого вылезают странные ошибки — жалуются в форумах, где им советуют "поправить вот здесь вот так". А привыкнув к такому подходу, начинает столь же бездумно лепить шаблонные конструкции для организации/обработки данных. И вместо прозрачного языка с контролируемым объемом и быстродействием программы получается еще один "язык выражения намерений программиста", которых и без того множество.
Я вот, например, в токостях и сейчас не понимаю часто, как работает SFINAE, и без шаблонных рекурсий
Современные версии всю эту возню со SFINAE упрощают/заменяют
M>>Чем тебе стандартная библиотека, и её развитие, не нравится — тоже не понятно.
ЕМ>Тем, что она давно подмяла язык под себя, предложив извращенную реализацию того, что должно быть нормально реализовано в компиляторе. По уму, ее давно нужно было выделить в отдельный стандарт и разбить на уровни, реализация которых опциональна.
Ничего она не подмяла. Под кейл, вон, армовский только компилер 11 версии стандарта, а либа — еще RogueWave от девяносто лохматого года. И нормально, в общем-то, живётся
Здравствуйте, so5team, Вы писали:
ЕМ>>А привыкнув к такому подходу, начинает столь же бездумно лепить шаблонные конструкции для организации/обработки данных.
S>Можно пример подобного?
Я сам такое не практикую, поэтому конкретных примеров под рукой нет, но встречается это часто. Сами-то конструкции комбинировать несложно, и это нередко даже выглядит изящно, но несколько вложенных уровней разворачиваются в неслабого объема код, уменьшить который не всякий оптимизатор способен.
Здравствуйте, rg45, Вы писали:
R>Просто интересно стало, на чем основаны эти утверждения про большинство. Как ты статистику собирал?
Может, конечно, это и иллюзия, но вопросы типа "а почему так?" и жалобы на "не работает" встречаются часто и обильно. И с институтских времен помню, что теория формальных языков у большинства шла с большим скрипом, у них в голове не укладывалось, каким образом правило что-то там порождает. Оно и понятно — мышление физически заточено под итеративные конструкции, а не рекурсивные. Но традиционная для ЯП "исполняемая" рекурсия обычно легко сводится к итерации, поэтому ее легче понять. А вот когда она "порождающая" — у большинства как раз крыша и едет.
Уточняю: "большинство" — это среди всех программистов, а не только успешных и результативных.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Можно пример подобного?
ЕМ>Я сам такое не практикую, поэтому конкретных примеров под рукой нет, но встречается это часто. Сами-то конструкции комбинировать несложно, и это нередко даже выглядит изящно, но несколько вложенных уровней разворачиваются в неслабого объема код, уменьшить который не всякий оптимизатор способен.
Этот неслабого объема код только на эмбеде или в ядре имеет значение, в остальных случаях результат всё равно на порядки меньше и быстрее, чем на всяких джавах и прочих модных языках.
А в эмбеде или в ядре — ну да, нужно поаккуратнее писать
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Может, конечно, это и иллюзия, но вопросы типа "а почему так?" и жалобы на "не работает" встречаются часто и обильно. И с институтских времен помню, что теория формальных языков у большинства шла с большим скрипом, у них в голове не укладывалось, каким образом правило что-то там порождает. Оно и понятно — мышление физически заточено под итеративные конструкции, а не рекурсивные. Но традиционная для ЯП "исполняемая" рекурсия обычно легко сводится к итерации, поэтому ее легче понять. А вот когда она "порождающая" — у большинства как раз крыша и едет.
Хм. Мне вот например рекурсию написать гораздо проще, чем её развернуть в итеративный алгоритм. И сложилось впечатление, что это для большинства так
Здравствуйте, Marty, Вы писали:
ЕМ>>Вряд ли дело в стандартах — скорее всего, просто оптимизаторы стали лучше работать.
M>Из-за constexpr'а, да
Грамотному оптимизатору constexpr (как и const) не требуется — он может сам увидеть, константно ли выражение. Конструкции const/constexpr нужны больше для строгости.
M>И в чем проблема?
С исключениями — ни в чем. А с шаблонами — в том, что их давно и массово используют извращенным способом, громоздя весьма запутанные конструкции, поэтому редкий (в общей массе) программист адекватно представляет себе, во что развернется конструкция, которую он пишет в программе, и становится похожим на того юзера, который сперва жмет "предпоследнюю кнопку справа", затем выбирает "третий пункт меню", и ставит галочку в "верхней строке списка".
M>Современные версии всю эту возню со SFINAE упрощают/заменяют
Каким образом?
M>Под кейл, вон, армовский только компилер 11 версии стандарта, а либа — еще RogueWave от девяносто лохматого года.
Так это и означает "реализация языка не соответствует стандарту". А если б на язык и основные части библиотеки были отдельные стандарты, в них и разбираться было бы гораздо проще, и реализовать в полном соответствии стандарту.
Здравствуйте, Marty, Вы писали:
M>Так и пользуйся тем, что нравится. Никто же не заставляет прям всем пользоваться
Ситуация примерно такая:
Выходит новый стандарт (несколько тыщ страниц).
Появляются компиляторы, частично его реализующие.
Народ начинает внедрять новые модные фичи, по делу и без.
Обновляешь зависимости -> не компилируется ибо новые фичи
Обновляем компилятор -> упс старая ос, нужна свежая, производители компиляторов люди прогрессивные и очень занятые так что не поддерживают старые платформы.
Обновляем всё -> компилируем -> не проходит тесты
Ищем, устраняем, подстраиваемся под новыю ос -> собираем -> черт уже новый стандарт
Как плюс, проект теперь собирается только новым компилятором и на старых ос уже не пускается. А для запуска на старой ос слишком много телодвижений надо — забиваем.
Особенно хорошо это для остальных языков программирования которые собираются из плюсов. Они тоже переходят в разряд только на новых ос.
Тем самым сжигаем мосты и сами закапываем, то что работает.
А потом смотрим репозиторий: о проект не обновлялся 2года (автор помер) — всё швах использовать нельзя проект не развивается.
Когда в C++ появятся конструкции которые в явном виде ограничивают использование фич языка (как старых так и новых).
Простой вопрос как имея c++ файл определить минимальную и максимальную версию стандарта который нужен его компиляции?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, ioni, Вы писали:
I>>Вроде как этот? I>>https://isocpp.org/files/papers/N4860.pdf
ЕМ>Интересно, это 1800 страниц — это рекорд по объему стандарта на язык программирования, или есть больше?
Язык там описан на 458 страницах. Остальное -- вредный довесок в виде "стандартной библиотеки". Торговля с нагрузкой.
ЕМ>У большинства других языков это попросту не входит в парадигму. Уникальность C — в том, что в нем принципиально нет языковых конструкций, могущих породить объемный и/или тормозной код. C++ это унаследовал, и единственной чисто языковой фичей, которая могла дать избыточный код или тормоза, были исключения. Но их и невозможно было реализовать иначе, поэтому к ним нет претензий.
Вот тут ты абсолютно прав и на 100% попал в точку. Множество людей работающих близко к железу иногда даже сами не понимают за что они любят С. А вот именно за то, (не буквально но суть отражает) что быстро окинув код взглядом можно тут же оценить насколько это быстро и насколько это много в ассемблерном выхлопе, а это очень важно в их работе и зачастую является ключевым фактором. Однако это верно только если мы сами пишем код и досконально знаем каждый метод и что примерно делает каждая функция и знаем цену сторонних функций которые вызываем. То же можно сказать о С++ коде. Если ты сам пишешь весь код, то ты вполне в состоянии его контролировать. Если ты используешь сторонний код, то должен быть уверен в его эффективности.
ЕМ>А вот когда вдруг обнаружилось, что на шаблонах можно делать то, что в других условиях обязан делать сам язык — получение сведений о типах/объектах, их взаимосвязях и прочие compile-time сервисы — и этот подход был признан правильным, тогда и началась вакханалия. Большинство ведь толком не понимает, как работает шаблонная рекурсия, завязанная на SFINAE, поэтому тупо копирует рекомендованные конструкции из учебников; если после этого вылезают странные ошибки — жалуются в форумах, где им советуют "поправить вот здесь вот так". А привыкнув к такому подходу, начинает столь же бездумно лепить шаблонные конструкции для организации/обработки данных. И вместо прозрачного языка с контролируемым объемом и быстродействием программы получается еще один "язык выражения намерений программиста", которых и без того множество.
Да, на шаблонах можно написать что угодно громоздкое, особенно если задаться этой целью, как и на С . Но шаблоны это мета-програмирование, это программирование языка программирования и 90% случаев весь код выполняется на этапе компиляции и ничего не отнимает ни в плане скорости ни в плане размера программы. Непринятие "чистыми" С программистами шаблонов С++ основывается на их профессиональной привычке, что много кода — медленно, большой объем программы. Это не более чем привычка.
Я вполне согласен что системщикам не нравится неявные вызовы new/delete или исключения, тем более в ядре, где невозможно явно контролировать реализацию. Ну так и не используйте их. Зато в современном С++ появилась масса вещей которые можно делать прямо во время компиляции и с помощью которых можно автоматизировать написание большого объема почти одинакового кода, которой на С все-равно придется писать.
Чем, например системному программисту может навредить RAII? Если вы не используете динамическое аллоцирование (new/delete), то и исключений в конструкторе быть не может.
Чем вам помешают STL-ные: array, string_view, optional, variant ? Там гарантированно не будет никаких аллокаций и исключений если вы их не используете в своих классах.
Чем плох constexr ?
ЕМ>Тем, что она давно подмяла язык под себя, предложив извращенную реализацию того, что должно быть нормально реализовано в компиляторе. По уму, ее давно нужно было выделить в отдельный стандарт и разбить на уровни, реализация которых опциональна.
Да это и так все уже давно сделано. Не включай не нужные заголовки, не включай RTTI, не используй new/detete. Будет тебе по скорости тот же С, только намного мощнее и с шаблонами. Я, например, вообще не использую ужасно спроектированное тормозное и неудобное I/O. Можешь — используешь vector, string, map. Хочешь — пиши свои. Но зато, часто на практике, по самой задаче просто нужно написать много "шаблонного" кода. Обычно это какие-то табличные вещи, таблицы маршрутизации, какие-то множества структур. Тут С не может дать ничего в помощь разработчику. Начинается кто в лес кто по дрова: какие-то препроцессоры, сторонние генераторы и т.д.
Здравствуйте, 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 не особо сложно.
