Здравствуйте, alex_public, Вы писали:
_>Однако в силу особенностей реализации шаблонов на C++ (в том числе принципа нулевого оверхеда, выносящего шаблоны исключительно на уровень времени компиляции) совершенно неожиданно оказалось, что шаблоны пригодны и для реализации другой парадигмы, а именно метапрограммирования (опять же времени компиляции). А МП — это пожалуй мощнейший инструмент в программирование, правда требующий весьма умелых рук. Ну и да, МП код на шаблонах выглядит довольно страшненько по сравнению с аналогами, созданными специально для этой цели (например в сравнение с макросами Rust'a и т.п.). Однако подобный код в любом случае на голову мощнее и удобнее аналогов из тех языков, в которых вообще нет встроенных средств МП (ну или же так называемого "C с классами" — устаревшего подмножества C++, используемого некоторыми).
А что почитать по этой теме чтобы побыстрее вникнуть и разобраться в чем там суть и как это применять на практике? Какая-нибудь хорошая книжка есть?
Здравствуйте, smeeld, Вы писали:
S>если оно на плюсах, то участки кода, которые максимально под нагрузкой -выводят в шаблоны. Не для какого-то удобства, или дани традиции, или обобщения, а именно для лучшей оптимизируемости компилятором.
Можете сказать что это за методика (код под нагрузкой выводить в шаблоны), где про нее прочитать? Почему шаблонный код лучше оптимизируется? Что при этом должно являться параметром шаблона?
Здравствуйте, antropolog, Вы писали:
_>>Ну посмотри какие в последнее время обсуждаются предложения в стандарт, какие вещи обсуждаются на конференциях и т.п. Причём заметь, что ты там не найдёшь никаких мыслей о светлом будущем какой-то глобальной метапрограммной функции (ну не считая конечно же революционного предложения Саттера о метаклассах, которое в случае принятия перевернёт вообще всё программирование на C++) — все просто используют подобные техники уже сейчас, в каждодневных мелочах. Это и есть мейнстрим. A>а причём здесь стандарт? Понятно что библиотеки общего назначения невозможно реализовать эффективно без шаблонов/метапрограммирования. Но в моём понимании "мейнстрим" это не то, что обсуждается на конференциях, и тем более в стандарте, а то, что используется в проектах повседневно и массами ( по определению слова "мейнстрим" ).
Ты видимо не внимательно прочитал моё сообщение. У меня как раз написано, что подобные вещи НЕ обсуждаются на конференциях и т.п. Они просто повседневно используются и всё. А посмотреть на конференции, предложения в стандарт и т.п. я предлагал в том смысле, чтобы увидеть какие люди используют данные приёмы в своём повседневном коде.
A>И здесь я не наблюдаю никакого движения в сторону мета-программирования, или всеобщей "шаблонизации", и мне совершенно очевидно что подобного никогда не случится, т.к. место шаблонной машинерии в библиотеках общего назначения и не более.
Ну если ты не наблюдаешь, то это всего лишь определённым образом характеризует окружающую тебя среду и всё — не стоит мерить по ней весь мир.
A>Ну и ещё, насчёт "мейнстрима", проблема (да, я считаю это проблемой) что C++ коммьюнити одержимо сложностью ( статья 5-летней давности https://news.ycombinator.com/item?id=16270755 ), и я нахожу данный факт негативно влияющим на развитие C++ как языка так и коммьюнити. Потому что вот это вот отношение а-ля "не пишет всё на шаблонах — лох", которое и у тебя в том числе прослеживается даже в этой теме, оно не просто ошибочно, но и губительно.
На самом деле речь естественно не только о шаблонах, но и обо всех современных возможностях языка. Тут и полиморфные лямбды и семантика перемещения (это кстати вообще текущая киллер-фича языка) и пользовательские литералы и декомпозиция кортежей и if constexpr и всяческие optional/variant/visitor/string_view и ещё миллион разных мелких удобностей, привносимых текущим стандартом языка.
Здравствуйте, antropolog, Вы писали:
_>>Знака равенства нет. Второе, очевидно является подмножеством первого. Т.е. умение применять шаблоны — это необходимое, но не достаточное условие хорошего знания современного C++. A>ты здесь подменил тезис. Я говорил не об умении применять шаблоны, а об их повседневном использовании. Потому что в моём понимании хорошо знает C++ не тот, кто умеет применять шаблоны, а тот кто умеет их не применять (стандартные стадии мастерства: не умею использовать, умею использовать, умею не использовать).
Только вот похоже что тут на форуме встречаются люди, находящихся на первой ступени, но думающие, что они на третьей. )))
Здравствуйте, lpd, Вы писали:
_>>Безусловно, программист на Питоне не может считаться отсталым за своё незнание шаблонов C++. Только вот непонятно, какое отношение к обсуждаемой теме имеет этот очевидный тезис? )
lpd>Да нет никаких "программистов на C++". Программистов можно условно делить на backend, frontend, и, может, скриптовиков.
Какое милое разделение. Интересно, а например код для микрокотроллеров к какой из этих трёх категорий относится? )))
lpd>Программисту несложно перейти с C++ на Java или даже на python, если у него есть базовые знания, поскольку ключевое — знание технологий а не тонкости языка.
Да, с C++ перейти на эти языки не сложно. А вот как насчёт обратного направления? ) Ты действительно считаешь, что Java или Python программист сможет с ходу писать эффективный код на C++? ) Кстати, программисту на Java или C# тут скорее всего будет тяжелее всего, т.к. их старый код с минимальными правками будет с ходу работать и на C++, только вот он при этом будет раз в 10 (а иногда и в 100) медленнее, аналогичного кода написанного в стиле настоящего C++.
lpd>Последние нововведения языков программирования — один из предметов для хобби, если именно это интересно, но не являются необходимыми знаниями. Вокруг новых стандартов C++ есть очевидный хайп, однако направление развития C++ ничем не важнее D, Lisp и других языков программирования, даже если шаблоны и rvalue-reference проникли в stl.
Ну да, это всего лишь позволяет писать нам более эффективный и лаконичный код. Но зачем нам надо повышение производительности труда, если "и так сойдёт", да? )))
Здравствуйте, Максим Рогожин, Вы писали:
МР>А что почитать по этой теме чтобы побыстрее вникнуть и разобраться в чем там суть и как это применять на практике? Какая-нибудь хорошая книжка есть?
Можно начать с древней классики, типа такой. Правда там совсем не современный C++ и имеется немного "фанатизма", но зато там виден базис, с которого стартовало всё это направление.
P.S. Лично я уже довольно давно не читаю никаких книг по программированию. Читаю в основном документацию (в случае C++ — это стандарт языка, в виде единого документа http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf или в более удобном иерархическом виде как здесь http://en.cppreference.com/w/, если там уже успели добавить нужную информацию) или же различные статьи от экспертов в данной области (в случае C++ — это Страуструп, Саттер и т.п.). Иногда можно посмотреть видео тех же экспертов с конференций (типа таких https://www.youtube.com/user/CppCon/videos), но там очень много мусора (скучного и всем очевидного), так что тоже надо аккуратно выбирать по авторам, чтобы не терять зря время.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали: lpd>>Да нет никаких "программистов на C++". Программистов можно условно делить на backend, frontend, и, может, скриптовиков.
_>Какое милое разделение. Интересно, а например код для микрокотроллеров к какой из этих трёх категорий относится? )))
embedded можно условно отнести к backend, т.к. backend-программисту желательно понимать принципы работы ядра, и это точно приоритетнее C++14.
lpd>>Программисту несложно перейти с C++ на Java или даже на python, если у него есть базовые знания, поскольку ключевое — знание технологий а не тонкости языка.
_>Да, с C++ перейти на эти языки не сложно. А вот как насчёт обратного направления? ) Ты действительно считаешь, что Java или Python программист сможет с ходу писать эффективный код на C++? )
Не знаю как сейчас, а раньше на Java обычно переходили с C++. Да и сейчас нужно только разобраться с компилятором/линковщиком и привыкнуть к указателям.
lpd>>Последние нововведения языков программирования — один из предметов для хобби, если именно это интересно, но не являются необходимыми знаниями. Вокруг новых стандартов C++ есть очевидный хайп, однако направление развития C++ ничем не важнее D, Lisp и других языков программирования, даже если шаблоны и rvalue-reference проникли в stl.
_>Ну да, это всего лишь позволяет писать нам более эффективный и лаконичный код. Но зачем нам надо повышение производительности труда, если "и так сойдёт", да? )))
Я понял, тебе просто нравится лес из угловых скобочек, поэтому ты ищешь любые оправдания для создаваемых тобой вариадиков и shared_ptr. При этом для доказательства своей позиции не гнушаешься аппелировать к авторитету комитетов C++ и boost, а также цитируешь выступления других фанатиков с C++ конференциий. Все свои аргументы я привел, однако рациональные доводы ты отметаешь. Будем надеяться, что история не будет долго затягивать с разрешением этого конфликта последователей Александреску и скептиков, и завершим спор о субъективных вещах.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, vopl, Вы писали:
V>>например, вот такую штуку без метапрограммирования ой как трудно было бы замутить: O Boost Multi-index Containers
MTD>Вундервафля любопытная,
Вундервафля говоришь..
Это инструмент. Для него есть практически полезные варианты использования и их не так уж и мало.
MTD>но совершенно бесполезная.
Здравствуйте, lpd, Вы писали:
lpd>>>Да нет никаких "программистов на C++". Программистов можно условно делить на backend, frontend, и, может, скриптовиков. _>>Какое милое разделение. Интересно, а например код для микрокотроллеров к какой из этих трёх категорий относится? ))) lpd>embedded можно условно отнести к backend, т.к. backend-программисту желательно понимать принципы работы ядра, и это точно приоритетнее C++14.
Прямо столько нового узнаю сегодня... Кстати, а если на МК программируется GUI, то это случаем не фронтендом станет?
_>>Да, с C++ перейти на эти языки не сложно. А вот как насчёт обратного направления? ) Ты действительно считаешь, что Java или Python программист сможет с ходу писать эффективный код на C++? ) lpd>Не знаю как сейчас, а раньше на Java обычно переходили с C++. Да и сейчас нужно только разобраться с компилятором/линковщиком и привыкнуть к указателям.
Вот в том то и дело, что программист на современном C++ указатели практически и не видит. А вот пришедший из Java обязательно в них вляпается, начав с привычного (и главное даже работающего) кода вида "new MyClass()".
_>>Ну да, это всего лишь позволяет писать нам более эффективный и лаконичный код. Но зачем нам надо повышение производительности труда, если "и так сойдёт", да? ))) lpd>Я понял, тебе просто нравится лес из угловых скобочек, поэтому ты ищешь любые оправдания для создаваемых тобой вариадиков и shared_ptr. При этом для доказательства своей позиции не гнушаешься аппелировать к авторитету комитетов C++ и boost, а также цитируешь выступления других фанатиков с C++ конференциий. Все свои аргументы я привел, однако рациональные доводы ты отметаешь. Будем надеяться, что история не будет долго затягивать с разрешением этого конфликта последователей Александреску и скептиков, и завершим спор о субъективных вещах.
shared_ptr кстати должен крайне редко использоваться (только для специфических задач) в современном C++, в отличие от unique_ptr.
Ну и если для тебя комитет C++, авторы boost'а и т.п. народ — это не авторитеты, а какие-то фанатики, то может тогда поделишься, кто же для тебя авторитет в данной области? )
Здравствуйте, rean, Вы писали:
lpd>>>Программисту несложно перейти с C++ на Java или даже на python, если у него есть базовые знания, поскольку ключевое — знание технологий а не тонкости языка. _>>Да, с C++ перейти на эти языки не сложно. А вот как насчёт обратного направления? R>Я не вижу никаких проблем в переходе с любого языка на любой, но при условии, что тот кто переходит, уже имеет в багаже опыт работы как минимум с пятью разными языками. R>Все-равно в итоге все упирается не в синтаксис и не в какие-то типичные паттерны, принятые в языке, а в библиотеки. После того как пять раз поменял языки, еще одна смена выглядит как типичная задача и уже не попадаешь на те ловушки, какие, возможно, сделал бы в первые разы.
Ага, ага, особенно если предыдущими языками были basic, 1C, php и т.п. замечательные языки. После них перейти на C++ просто элементарно будет.
_>>Кстати, программисту на Java или C# тут скорее всего будет тяжелее всего, т.к. их старый код с минимальными правками будет с ходу работать и на C++, только вот он при этом будет раз в 10 (а иногда и в 100) медленнее, аналогичного кода написанного в стиле настоящего C++. R>Не будет ничего медленным. Чтобы код был медленней в 10 раз, надо специально применять медленные алгоритмы. Или речь идет про микро-скорости, определяемые количеством простых линейных операций? Тогда да, то что можно сделать в рамках шаблона с инлайн-функциями, то пяток вызовов функций, где идет мешанина стека при каждом вызове, заменяется возможно одним вызововом или вообще все проинлайнится, и будет всего несколько ассемблерных команд.
Java программист может взять привычный ему код вида "MyClass my_object=new MyClass();" и перенести его на C++ банальным добавлением одной звёздочки. И что самое забавное, такое код будет корректно работать и делать буквально тоже самое, что и в Java. Только вот в итоге программа будет работать на порядки медленнее аналога, написанного нормальным C++ программистом. Потому как в 99% случае он напишет вместо вышеприведённого кода что-то вроде "MyClass my_object;". Понятно о чём я говорю? )
R>Только никакого особого смысла такое сокращение команд в общую скорость не внесет. Все-равно самый медленный ресурс для программы — это доступ к памяти и использование громоздких функций типа sin() в циклах.
Совершенно верно. И поэтому аллокация на стеке (стандартная вещь для C++ кода и полностью отсутствующая в таких языках как Java/C#) даёт огромные преимущества в производительности. Кстати, народ экспериментирующий со своими расширениями данных языков показывает какие цифры это может давать: http://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/.
R>В качестве примера могу свой опыт показать. Мне надо было работать с кадрами видео в режимах цветности с 8-бит на канал, 16-бит и в режиме float. R>Ну так вот, несмотря на то что между этими типами пропасть в скорости вычислений, разница была небольшой между ними: в режиме float примерно в полтора раза получалось медленней, с байтами. Хотя там еще была целочисленная сверхбыстрая арифметика. Все нивелировалось скоростью доступа к памяти.
А память была линейная? SIMD инструкции для загрузки данных из памяти использовались? )
R>Так что могу внести в ваш спор новый смысл: программист, не знающий как работает процессор с памятью, не сможет написать более эффективно чем человек, кто собаку съел на такого рода оптимизаций. Даже ассемблеровщик может потенциально написать более медленный код, если не понимает архитектуру компьютера.
Совершенно верно. Нюанс в том, что программист разрабатывающий эффективный код на C или C++ просто обязан знать все эти нюансы. А для написания эффективного кода на многих других языка эти знания просто не нужны (их там некуда применить).
Здравствуйте, so5team, Вы писали:
S>Что это: шизофрения?
Дорогой друг, не стану брать на себя ответственность ставить тебе диагноз по интернету, но судя по тому как ты возбуждаешься настоятельно рекомендую обратиться к специалисту, на всякий случай.
S>Очевидно, пруфы оказались для вас недостаточно убедительными, раз вы свою систему сериализации сделали на C++ных шаблонах, а не на C с ассемблером.
Так это just for fun — наколеночная либа, в продакшене С++ используют очень осторожно, хотя я новатор, да, но опять же — это никак в целом о индустрии не говорит.
Здравствуйте, Nikе, Вы писали:
N>Язык бедный, разработка и рефакторинг на нём сложны, из-за чего страдает качество кодирования. Чтобы успеть к срокам (и без того сильно завышенным) люди не уделяют достаточно времени ручной оптимизации, в то время, как на С++ она зачастую получается автоматом.
О каких оптимизациях речь? Вот я как практик, сразу могу сказать, что например, использование STL зачастую напрочь убивает перформанс.
N>Это, конечно не аргумент, но просто байка: занимались мы созданием opengl дров для одной корпорации. Для чего взяли какую-то готовую на С++ (кроносовскую, вроде) и, по требованию заказчика (времена были старые, хорошие компиляторы были не везде) переписали её на С. Производительность сразу упала процентов на 10. В итоге пришлось долго сношаться, чтобы её поднять обратно.
Да, это не аргумент, ни о чем кроме прямоты рук это не говорит.
Здравствуйте, Nikе, Вы писали:
MTD>>Вот только отчего-то такие куски кода отчего-то все больше на чистом С пишут, а иногда и ассемблере, так как это дает больший контроль над кодом N>О, да! Это отлично. А потом мне платят огромные деньги за переписывание этого на нормальный язык программирования
А это не ты тот забавный чувак, который утверждает, что никого найти невозможно за 300К, но на предложение приехать на беседу моментально сливается? Подозреваю, что достоверность остальных твоих баек заслуживают аналогичного уровня доверия
Здравствуйте, MTD, Вы писали:
S>>Что это: шизофрения?
MTD>Дорогой друг, не стану брать на себя ответственность ставить тебе диагноз по интернету, но судя по тому как ты возбуждаешься настоятельно рекомендую обратиться к специалисту, на всякий случай.
Поскольку исходный вопрос звучал так: "Что это: троллинг или, что хуже, шизофрения?", то вариант с троллингом, очевидно, отпадает сам собой.
MTD>в продакшене С++ используют очень осторожно
Как оно там, в начале 1990-х?
MTD>хотя я новатор, да
Здравствуйте, MTD, Вы писали:
MTD>использование STL зачастую напрочь убивает перформанс. MTD>Да, это не аргумент, ни о чем кроме прямоты рук это не говорит.
Здравствуйте, alex_public, Вы писали:
_>Ну и если для тебя комитет C++, авторы boost'а и т.п. народ — это не авторитеты, а какие-то фанатики, то может тогда поделишься, кто же для тебя авторитет в данной области? )
Языками программирования самими по себе я интересуюсь мало. Сейчас бы я аппелировал к: “Everything should be made as simple as possible, but no simpler.” A. Einstein
Значительные изменения в ИТ в будущем предполагаю в появлении новой ОС и, возможно, в ИИ, а не в развитии C++.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, so5team, Вы писали:
S>Поскольку исходный вопрос звучал так: "Что это: троллинг или, что хуже, шизофрения?", то вариант с троллингом, очевидно, отпадает сам собой.
Сочувствую. Что лечащий врач говорит? Надежда есть?
MTD>>в продакшене С++ используют очень осторожно
S>Как оно там, в начале 1990-х?
Хз, как тогда было, я тебе рассказал как сейчас, не в провинциальных конторках из 2 с половиной землекопов на заказ клепающих автоматизацию учета посещения местного сортира, а у лидеров индустрии в России (тут мне несколько виднее, чем тебе, увы).
MTD>>хотя я новатор, да
S>Да-да. Новатор.
