Информация об изменениях

Сообщение Re[7]: C++ 20 приняли от 07.01.2021 18:28

Изменено 07.01.2021 18:36 Videoman

Re[7]: C++ 20 приняли
ЕМ>У большинства других языков это попросту не входит в парадигму. Уникальность 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. Хочешь — пиши свои. Но зато, часто на практике, по самой задаче просто нужно написать много "шаблонного" кода. Обычно это какие-то табличные вещи, таблицы маршрутизации, какие-то множества структур. Тут С не может дать ничего в помощь разработчику начинается кто в лес кто по дрова — какие-то препроцессоры, сторонние генераторы и т.д.
Re[7]: C++ 20 приняли
ЕМ>У большинства других языков это попросту не входит в парадигму. Уникальность 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. Хочешь — пиши свои. Но зато, часто на практике, по самой задаче просто нужно написать много "шаблонного" кода. Обычно это какие-то табличные вещи, таблицы маршрутизации, какие-то множества структур. Тут С не может дать ничего в помощь разработчику. Начинается кто в лес кто по дрова: какие-то препроцессоры, сторонние генераторы и т.д.