Здравствуйте, lpd, Вы писали:
lpd>Теперь снова занимаюсь ядром линукса, и от классов с наследованием бы не отказался
В ядре еще неплохо помогли бы атрибуты объектов/функций, наследуемые по цепочке использования. Например, есть некий общий ресурс ядра (список процессов, выделенных страниц памяти и т.п.), который нельзя захватывать в специальных режимах (при обработке прерывания, при выполнении callback'а и т.п.). Вешаем на функцию его захвата атрибут A, на функции вызова обработчиков прерываний — атрибут B, и вводим правило, что атрибуты A и B несовместимы. Тогда любая функция, явно вызванная (непосредственно или опосредованно) из обработчика прерывания, не сможет явно же вызвать функцию захвата ресурса.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, lpd, Вы писали:
EP>Ты путаешь мягкое с тёплым, одно другому не мешает, не противоречит, и не исключает. EP>В том числе и в графике:
ffmpeg/libavcodec написаны на С с редкими вставками ассемблеров, без шаблонов.
А в твоем видео вроде как классический С++ с простыми шаблонами, некоторую пользу которых для контейнеров я не отрицаю.
Оптимизация алгоритма может дать выигрыш быстродействия во много раз. Есть опыт, насколько современный С++ ускорял код по сравнению с классическим?
lpd>>И возникающие в процессе работы проблемы С++, тем более современный, не решил бы.
EP>Современный упрощает код, причём местами на порядок.
Это шутка такая? По-моему современный С++ не проще японского языка, и не сильно для меня полезнее.
Я вообще не особенно честно говоря в курсе, что такого можно сделать на современных шаблонах, чего нельзя сделать на полиморфизме и RTTI? Или вопрос только в быстродействии? Если последнее, то оптимизировать нужно только отдельные участки программы, и сделать это вполне можно без шаблонов и мув-семанитки, вручную. Я бы не стал городить лес из скобочек и двойных амперсандов, но похоже что это вопрос вкуса.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Оптимизация алгоритма может дать выигрыш быстродействия во много раз.
И? В чём поинт-то? Типа "давайте не будем использовать современный C++, а будем писать на C или на старом лампово C++, потому что мы крутые перцы и мы-то оптимизируем алгоритмы, а те кто используют современный C++ этого не делают, и думают что rvalues спасут их медленные алгоритмы"?
lpd>Есть опыт, насколько современный С++ ускорял код по сравнению с классическим?
Странный вопрос.
1. Я могу написать на C++98 такой же быстрый и такой же обобщённый код как и на современном, но этого кода местами будет намного больше. Этот код будет намного сложее и менее понятным.
2. Точно также как же как и на C я смогу написать код таким же быстрым как и на современном C++, только этого кода будет больше в разы, а то и на порядки. Воороужившись кодогенератором, я смогу его даже сделать обобщённым.
3. Я могу написать на Java код близкий по производительности к C++, только этого кода будет даже больше чем на C, и я даже не рискнул бы делать это вручную, а например бы просто генерировал бы его из современного C++, точно также как и Emscripten генерирует быстрый (насколько это возможно) JavaScript из C++, который даже обгоняет C#
.
lpd>>>И возникающие в процессе работы проблемы С++, тем более современный, не решил бы.
EP>>Современный упрощает код, причём местами на порядок. lpd>Это шутка такая? По-моему современный С++ не проще японского языка, и не сильно для меня полезнее.
Нет конечно.
Я уже выше приводил пример с result_of протоколом — десятки строк достаточно специфичной писанины заменяются одним ключивым словом.
Или другой пример if constexpr — во многих местах заменяет эзотерический enable_if, делая код лаконичным И понятным.
lpd>Я вообще не особенно честно говоря в курсе, что такого можно сделать на современных шаблонах, чего нельзя сделать на полиморфизме и RTTI? Или вопрос только в быстродействии?
Вопрос в объёме кода, колличество строчек. Вопрос в читабельности кода.
lpd>Если последнее, то оптимизировать нужно только отдельные участки программы, и сделать это вполне можно без шаблонов и мув-семанитки, вручную.
Конечно можно, именно это и называется blub paradox.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, lpd, Вы писали:
lpd>>Оптимизация алгоритма может дать выигрыш быстродействия во много раз.
EP>И? В чём поинт-то?
Поинт в том, что фичи современного С++ в плане быстродействия — это во многих случаях микрооптимизации, по сравнению с алгоритмом.
А так большинство пишут код на Java/C#, который судя по бенчмаркам в 3 раза медленнее C/C++, и у них быстродействие упирается в сеть, в базу данных, и это все решается горизонтальным масштабированием.
lpd>>Если последнее, то оптимизировать нужно только отдельные участки программы, и сделать это вполне можно без шаблонов и мув-семанитки, вручную.
EP>Конечно можно, именно это и называется blub paradox.
Ну языков программирования много — просто C/C++ давно самые популярные и хайповые. Появись эти новые фичи в каком-нибудь редком языке, он не стал бы мейнстримовым. Я считаю язык программирования с его тонкостями не главным в разработке софта, по сравению с алгоритмом и архитектурой, и не слежу за новинками, да и другие интересы есть.
Но говорить что C++17 лучше, чем C++03 — это вкусовщина.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>>>Оптимизация алгоритма может дать выигрыш быстродействия во много раз. EP>>И? В чём поинт-то? lpd>Поинт в том, что фичи современного С++ в плане быстродействия — это во многих случаях микрооптимизации, по сравнению с алгоритмом.
Ты придумал какие-то тезисы, и сам с ними споришь игнорируя ответы. Вопрос не в сыром быстродействии, ибо оно доступно даже на C.
А в быстродейтсвии на колличество строк — чем новее C++, тем выше этот показатель.
То есть при одинаковом колличестве строк — современный C++ будет быстрее, либо таким же быстрым но при меньше колличестве строк.
lpd>А так большинство пишут код на Java/C#, который судя по бенчмаркам в 3 раза медленнее C/C++, и у них быстродействие упирается в сеть, в базу данных, и это все решается горизонтальным масштабированием.
Задачи и области разные бывают, вот уже надцать лет не работаю с базами данных, за исключением очень рекдих единичных эпизодов.
lpd>Я считаю язык программирования с его тонкостями не главным в разработке софта, по сравению с алгоритмом и архитектурой, и не слежу за новинками, да и другие интересы есть.
Опять двадцать пять. Кто тебе сказал что те кто используют современный C++ обязательно используют плохие алгоримты и проектируют плохую архитектуру?
lpd>Но говорить что C++17 лучше, чем C++03 — это вкусовщина.
Есть объективные показатели — напирмер колличество строк. Но да, кончено меньший объём кода это дело вкуса
Здравствуйте, Evgeny.Panasyuk, Вы писали:
lpd>>Но говорить что C++17 лучше, чем C++03 — это вкусовщина.
EP>Есть объективные показатели — напирмер колличество строк. Но да, кончено меньший объём кода это дело вкуса
Просто пишите весь код в одну строку.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но когда нужно модифицировать стандартный шаблон или сделать свой на похожих принципах, из-за того же непонимания механизма лепятся конструкции "лишь бы заработало". Как только заработало — задача считается решенной, даже если вызов разворачивается в "ужас-ужас", но кто смотрит, во что оно развернулось?
Я бы сказал, что это подмена понятий. Потому что язык C++ сам по себе тут не при чем. И даже программирование тут не при чем.
Такие люди есть во всех отраслях, это вопрос профпригодности по большому счету.
PS. Я понимаю, что имелось в виду, что "С++ провоцирует лепить конструкции "лишь бы заработало", но я с этим не согласен по причине демагогичности заявления: всегда есть некий уровень в любом деле, до которого не дотягиваются (не могут или не хотят) N специалистов, что и порождает с их стороны подобную работу "на отстань". Использовать это как аргумент в обвинении конкретного инструмента совершенно некорректно.
тёмка? ну так изучите С++ и будет вам счастье
