Долгая компиляция обусловлена необходимостью инстанциировать шаболоны и инлайнить всё, что плохо лежит. Это, безусловно, большой минус для пользователя, но и немалый плюс для получившейся на выходе компилятора программы, так что в итоге баланс соблюдается.
Насколько лично мне известно, std::ranges из C++20, предоставляющие функциональный доступ к контейнерам, чуть ли не только в "плюсах" могут работать так же быстро, как написанные от руки циклы, и именно благодаря этой фиче компилятора.
Полотна ошибок же в шаблонном коде давно стали притчей во языцах, но ситуация начинает улучшаться: концепты позволят проверять соответствие интерфейса при вызове библиотечных функций, а не глубоко внутри них, как это было раньше.
Ну то есть, разумеется, медленность сборки сама по себе — конечно, большой минус, тут и обсуждать нечего. Все хотели бы ускорить сборку.
Но всё это ведь во имя большой цели — кодогенерации и вычислений всего, чего можно, в компайл-тайме. Благодаря строгой типизации и шаблонным алгоритмам C++ позволяет наворотить абстракций, и получить почти такое же быстрое выполнение, как без них.
общеизвестный пример про стандартные алгоритмы
В то время как сишная функция qsort вынуждена принимать указатель на функцию сравнения, std::sort может заинлайнить компаратор, избавившись от лишних переходов по указателю. Но да, ценой инстанциирования шаблонов на этапе компиляции, инлайнинга, вычислений constexpr… Всё это небыстро.
Поскольку всё сразу хорошо не бывает, мне кажется, к этому следует относиться именно как к двум сторонам одной медали. Ну и никто не заставляет писать на плюсах там, где они не нужны. Можно же выбирать инструмент под задачу.
Программирование UI и хорошие практики в нём - отдельная тема, не очень связанная с языком программирования. Хотя, безусловно, интересная, и очень важная для тех разработчиков, кому приходится этим самым UI заниматься.
В своём бенчмарке я хотел показать, что передача по ссылке более эффективна, чем RVO, при условии, что где-то уже существует заранее выделенный контейнер (например, это статический thread_local объект).
Если же объект создаётся всегда новый - никакой разницы, конечно же, не будет.
К сожалению, стандартных типов для корутин ввести(как и добавить их поддержку в std::future) ещё не успели, если повезёт, появятся в С++23, если нет — придётся городить свои или пользоваться библиотекой Folly или чем-то подобным.
Нет, такого быть, конечно, не может — тут явно сработала оптимизация, компилятор ведь видит, что переменная не используется. Добавление в обоих случаях benchmark::DoNotOptimize возвращает пример на круги своя
Не имею ничего против функционального подхода (я очень даже за), но, несмотря на то, что в простом случае оба варианта и реализованы примерно одинаково, вариант с аргументом чуть универсальнее: может записать данные в существующий массив, выделенный заранее. Могу ошибаться, но сомневаюсь, что RVO сможет понять, что мы хотим писать в существующий объект.
Попробовал даже забенчмаркать, результат с возвратом по значению довольно в два раза дольше :/
Так что лично я действую по ситуации. Вариант с возвратом выглядит чище и красивее, но иногда, при переиспользовании массива, лучше олдскульный вариант.
Да, вы совершенно правы, несмотря на то, что за очень редким исключением язык де-факто обратно совместим с C (про де-юре это сказать трудно, некоторый сишный код приводит к undefined behavior), у сообщества C++ сформировался специфический набор идиом и подходов, характерный только для этого языка. Так что хороший сишник вряд ли быстро станет хорошим плюсовиком, так же как и хороший плюсовик быстро не станет хорошим сишником.
С "другой стороны баррикад" могу сказать, что лично меня как раз раздражает необходимость обращаться с кодом в стиле "C с классами", или сишными библиотеками. Фундаментальные библиотеки обычно написаны именно на C, тому есть веские причины, и это одновременно проклятье и благословение. С одной стороны, нам не приходится изобретать велосипеды и отказываться от проверенных поколениями разработчиков библиотек, с другой - прикручивать к своему коду всё это довольно неудобно.
Полностью с вами согласен в отношении к загрязнению Земли и окресностей, но к популярной цитате имею претензию: в ней вместо "человечество" можно смело подставлять слово "жизнь", смысл не изменится.
А поскольку раковая опухоль сама по себе живая и эволюционирующая, всё упрощается вообще до "жизнь - это болезнь планеты"...
С другой стороны, разум - фича с уникальным соотношением силы и ответственности. С его помощью мы сможем либо разрушить вообще всё, либо наконец-то ограничить расход ресурсов.
Ни разу именно эту штуку не видел и говорить предметно не могу, но рискну предположить, что не в классах и количестве их слоёв дело, скорее — в том, какие именно абстракции используются и сможет ли компилятор их оптимизировать или нет.
Идиоматичные обёртки на C++ могут быть вполне себе zero-cost, на хабре есть несколько статей на тему, вот одна из них.
С другой стороны, (не знаю, как сейчас, но как минимум несколько лет назад) STMовский HAL был весьма тормозящей либой, даром что сишной и даже написанной производителем железок.
* в 11ом — лямбды, move-семантика, масштабное расширение стандартной библиотеки
* в 14ом — допиленные лямбды, гетерогенный поиск в упорядоченных map и set
* в 17ом — filesystem, структурированные байндинги, string_view, variant, optional, параллельные алгоритмы
* в 20ом — корутины, концепты, трёхстороннее сравнение, span, диапазоны
Комитет сделал за последние десять лет столько классных штук, что хочется больше и больше.
Впрочем, всё действительно сильно зависит от использования, и все действительно ждут разного. У меня ожидания и реальность разошлись впервые, и это всё равно очень здорово.
Прошу прощения, что-то взгрустнулось:
При всём уважении к Комитету, корутины(ну хотя бы awaitable future и generator!) в стандартной библиотеке всё ещё не завезли, контракты пока тоже идут лесом, до reflexpr тем более дело не дошло…
Безусловно, все свежие фичи вполне себе полезные, но почему-то пока совсем не вызывают былого ощущения «наконец-то добавили то, чего больше всего не хватало».
В любом случае, огромное спасибо за статью, и особенно — за нелегкое и местами неблагодарное(при появлении комментаторов вроде меня :) ) дело работы над стандартом!
PS: за паттерн матчинг всё прощу, и другие фичи вызывают надежду — дождаться бы.
Вообще, как-то все загадочно с грибами: не растения, не животные
Просто грибы - это грибы, отдельное царство, такое же, как растения, животные и простейшие :) У нас с ними есть общие предки, и они, кажется, разошлись с животными не сильнее, чем растения.
Мне кажется, грибы кажутся людям чужеродными только лишь потому, что мы сталкиваемся с этой формой жизни не так часто, как с растениями.
таких, что ты им на вход компост, а на выходе ракетное топливо
Ну, это ведь тоже не вечный двигатель, просто он будет работать на компосте, а не ракетном топливе...
Кстати, кольцо, как отличительный признак опят - как мне кажется, очень опасный критерий, который почему-то до сих пор упоминается повсеместно.
Несмотря на название, большинство распространённых ложноопят - вполне съедобные и даже довольно вкусные грибы. Те же, что ядовитые (ложноопёнок серно-желтый, под некоторым вопросом кирпично-красный) - чреваты только обычным расстройством пищеварения.
При этом у вышеупомянутой галерины окаймлённой, жутко ядовитого гриба с аматоксином, кольцо как раз есть, растёт она иногда рядом с нормальными опятами, и при этом во многих статьях для начинающих грибников этот гриб не упоминают!
Идти к стоматологу, куда ж ещё. Врачи тоже бывают криворукими, и даже самый хороший специалист может совершить ошибку, но, сами понимаете, никто лучше их не умеет чинить ломающуюся тушку.
Вам, видимо, очень не повезло, да ещё и несколько раз подряд, я за всю жизнь побывал у стоматологов раз пятдесят, выдрал шесть зубов (мудрости, которых у меня шесть, а не четыре, как у нормальных людей плюс один обычный), ни раз не было даже сильно больно, не говоря уж о травмах.
Недостаток авторского решения в отсутствии синтаксической подсветки лямбд (стринга и стринга), но в случае изменения интерпретатора придётся и вовсе патчить плагин IDE, чтобы он тоже понимал такие выкрутасы… Хотя по производительности и правда гораздо дешевле
Извините, конечно, но разобраться по контексту, что делает та или иная конструкция, и написать её без знания языка — вещи совершенно разные.
Если угадать, что делает |x|*n по контексту(как и большинство других конструкций в других языках программирования) может большинство более-менее опытных разработчиков, то для того, чтобы додуматься так написать без примера, нужно обладать ну очень богатой фантазией.
Долгая компиляция обусловлена необходимостью инстанциировать шаболоны и инлайнить всё, что плохо лежит. Это, безусловно, большой минус для пользователя, но и немалый плюс для получившейся на выходе компилятора программы, так что в итоге баланс соблюдается.
Насколько лично мне известно, std::ranges из C++20, предоставляющие функциональный доступ к контейнерам, чуть ли не только в "плюсах" могут работать так же быстро, как написанные от руки циклы, и именно благодаря этой фиче компилятора.
Полотна ошибок же в шаблонном коде давно стали притчей во языцах, но ситуация начинает улучшаться: концепты позволят проверять соответствие интерфейса при вызове библиотечных функций, а не глубоко внутри них, как это было раньше.
Ну то есть, разумеется, медленность сборки сама по себе — конечно, большой минус, тут и обсуждать нечего. Все хотели бы ускорить сборку.
Но всё это ведь во имя большой цели — кодогенерации и вычислений всего, чего можно, в компайл-тайме. Благодаря строгой типизации и шаблонным алгоритмам C++ позволяет наворотить абстракций, и получить почти такое же быстрое выполнение, как без них.
Поскольку всё сразу хорошо не бывает, мне кажется, к этому следует относиться именно как к двум сторонам одной медали. Ну и никто не заставляет писать на плюсах там, где они не нужны. Можно же выбирать инструмент под задачу.
Программирование UI и хорошие практики в нём - отдельная тема, не очень связанная с языком программирования. Хотя, безусловно, интересная, и очень важная для тех разработчиков, кому приходится этим самым UI заниматься.
упс, прошу прощения, в первый раз поторопился с ответом, не вглядевшись в код бенчмарка. Подправил ответ. Надеюсь, теперь получилось по существу >_<
В своём бенчмарке я хотел показать, что передача по ссылке более эффективна, чем RVO, при условии, что где-то уже существует заранее выделенный контейнер (например, это статический thread_local объект).
Если же объект создаётся всегда новый - никакой разницы, конечно же, не будет.
К сожалению, стандартных типов для корутин ввести(как и добавить их поддержку в std::future) ещё не успели, если повезёт, появятся в С++23, если нет — придётся городить свои или пользоваться библиотекой Folly или чем-то подобным.
Не имею ничего против функционального подхода (я очень даже за), но, несмотря на то, что в простом случае оба варианта и реализованы примерно одинаково, вариант с аргументом чуть универсальнее: может записать данные в существующий массив, выделенный заранее. Могу ошибаться, но сомневаюсь, что RVO сможет понять, что мы хотим писать в существующий объект.
Попробовал даже забенчмаркать, результат с возвратом по значению довольно в два раза дольше :/
Так что лично я действую по ситуации. Вариант с возвратом выглядит чище и красивее, но иногда, при переиспользовании массива, лучше олдскульный вариант.
Да, вы совершенно правы, несмотря на то, что за очень редким исключением язык де-факто обратно совместим с C (про де-юре это сказать трудно, некоторый сишный код приводит к undefined behavior), у сообщества C++ сформировался специфический набор идиом и подходов, характерный только для этого языка. Так что хороший сишник вряд ли быстро станет хорошим плюсовиком, так же как и хороший плюсовик быстро не станет хорошим сишником.
С "другой стороны баррикад" могу сказать, что лично меня как раз раздражает необходимость обращаться с кодом в стиле "C с классами", или сишными библиотеками. Фундаментальные библиотеки обычно написаны именно на C, тому есть веские причины, и это одновременно проклятье и благословение. С одной стороны, нам не приходится изобретать велосипеды и отказываться от проверенных поколениями разработчиков библиотек, с другой - прикручивать к своему коду всё это довольно неудобно.
Полностью с вами согласен в отношении к загрязнению Земли и окресностей, но к популярной цитате имею претензию: в ней вместо "человечество" можно смело подставлять слово "жизнь", смысл не изменится.
А поскольку раковая опухоль сама по себе живая и эволюционирующая, всё упрощается вообще до "жизнь - это болезнь планеты"...
С другой стороны, разум - фича с уникальным соотношением силы и ответственности. С его помощью мы сможем либо разрушить вообще всё, либо наконец-то ограничить расход ресурсов.
Идиоматичные обёртки на C++ могут быть вполне себе zero-cost, на хабре есть несколько статей на тему, вот одна из них.
С другой стороны, (не знаю, как сейчас, но как минимум несколько лет назад) STMовский HAL был весьма тормозящей либой, даром что сишной и даже написанной производителем железок.
Кстати, std::expected тоже не хватало, здорово, что им занимаются.
* в 14ом — допиленные лямбды, гетерогенный поиск в упорядоченных map и set
* в 17ом — filesystem, структурированные байндинги, string_view, variant, optional, параллельные алгоритмы
* в 20ом — корутины, концепты, трёхстороннее сравнение, span, диапазоны
Комитет сделал за последние десять лет столько классных штук, что хочется больше и больше.
Впрочем, всё действительно сильно зависит от использования, и все действительно ждут разного. У меня ожидания и реальность разошлись впервые, и это всё равно очень здорово.
При всём уважении к Комитету, корутины(ну хотя бы awaitable future и generator!) в стандартной библиотеке всё ещё не завезли, контракты пока тоже идут лесом, до reflexpr тем более дело не дошло…
Безусловно, все свежие фичи вполне себе полезные, но почему-то пока совсем не вызывают былого ощущения «наконец-то добавили то, чего больше всего не хватало».
В любом случае, огромное спасибо за статью, и особенно — за нелегкое и местами неблагодарное(при появлении комментаторов вроде меня :) ) дело работы над стандартом!
PS: за паттерн матчинг всё прощу, и другие фичи вызывают надежду — дождаться бы.
Просто грибы - это грибы, отдельное царство, такое же, как растения, животные и простейшие :) У нас с ними есть общие предки, и они, кажется, разошлись с животными не сильнее, чем растения.
Мне кажется, грибы кажутся людям чужеродными только лишь потому, что мы сталкиваемся с этой формой жизни не так часто, как с растениями.
Ну, это ведь тоже не вечный двигатель, просто он будет работать на компосте, а не ракетном топливе...
Кстати, кольцо, как отличительный признак опят - как мне кажется, очень опасный критерий, который почему-то до сих пор упоминается повсеместно.
Несмотря на название, большинство распространённых ложноопят - вполне съедобные и даже довольно вкусные грибы. Те же, что ядовитые (ложноопёнок серно-желтый, под некоторым вопросом кирпично-красный) - чреваты только обычным расстройством пищеварения.
При этом у вышеупомянутой галерины окаймлённой, жутко ядовитого гриба с аматоксином, кольцо как раз есть, растёт она иногда рядом с нормальными опятами, и при этом во многих статьях для начинающих грибников этот гриб не упоминают!
Идти к стоматологу, куда ж ещё. Врачи тоже бывают криворукими, и даже самый хороший специалист может совершить ошибку, но, сами понимаете, никто лучше их не умеет чинить ломающуюся тушку.
Вам, видимо, очень не повезло, да ещё и несколько раз подряд, я за всю жизнь побывал у стоматологов раз пятдесят, выдрал шесть зубов (мудрости, которых у меня шесть, а не четыре, как у нормальных людей плюс один обычный), ни раз не было даже сильно больно, не говоря уж о травмах.
Отбросим аргументы шаблона, которые и так дефолтные, ну и заменим unordered_set на set для читаемости:
Если угадать, что делает |x|*n по контексту(как и большинство других конструкций в других языках программирования) может большинство более-менее опытных разработчиков, то для того, чтобы додуматься так написать без примера, нужно обладать ну очень богатой фантазией.