Comments 144
Отладка — это то, за что, в принципе, многие пользуются студией и готовы мириться с приколами компилятора, слабой оптимизацией, глючной STL и прочими багами.
там можно переключить на clang
На данный момент Visual Studio - лучший отладчик C++ в мире
Есть vs-code, который абсолютно также умеет отлаживать, но не привязан в платформе или компиляторам
Реальные полезные нововведения фактически закончились с выходом C++17, а попытки внедрить C++20 часто заканчиваются обнаружением множества "гейзенбагов" и существенным снижением производительности - критичные для нас на 10-15% от сборки к сборке.
на 10-15 % снизить производительность кода от сборки к сборке из-за переключения флажка на С++20 - это что-то прямо таки сказочное
Экономия на спичках (auto) тоже крайне сомнительно, никто не заставяет лепить везде auto, но выбирать между 3 лишними инструкциями исполненными компилятором и тем чтобы читать какой-то громадный ненужный в этом месте тип - просто странно. Зачем вообще думать об этих мелочах внутри компилятора, когда большая часть скорости сборки зависит совсем от других факторов? Что-то я подозреваю, что игровые проекты отнюдь не идеальны по коду, зависимостям от хедеров и ещё куче параметров, не лучше ли думать больше об этом, чем об лишней инструкции внутри компилятора?
погодите в узких местах, у нас условия игра, придётся думать о инструкциях, например как перемножаются матрицы банальный случай(без ускорения 1 скорость с инструкциями другая ), соотв там как по опыту решается думаю в узких местах, но с переносом и учитывая узкие места, я наверно солидарен со статьёй
Тут речь про скорость компиляции, а не про скорость исполнения кода в рантайме. Что с авто, что без, байт-код выходит одинаковый.
ну если это не движок, то пофиг на скорость компиляции, главное чтобы код понятный был и организация проекта, например под андроид 2 минуты собирает(пересобрать если всё) 2д игрушку мою - пазлер )
с движка готового всё равно управляемость только кодом проекта
А если это движок? То в чём проблема? У нас всё auto и это провоцирует программистов на то чтобы давать более внятные имена классам, методам, аргументам и переменным.
(Если что, у нас движок и набор тулзов)
А если "всё auto" - не появляется опасность получить float там, где нужен int, или наоборот?
В таких случаях в тех местах где такая опасность есть тип проставляется явно
Нет, особенно если нормально выставить ворнинги и диагностики. Профит от использования си++ всё равно на голову выше. Сейчас очень многие инструменты могут ткнуть носом если что-то не очень написано. При должном подходе получается очень быстрый и в меру надёжный код.
В vscode отладка несравнимо хуже, как, впрочем и в любых других средах разработки. CLion еще куда ни шло, но все равно до полноценной VS ему как до Китая раком.
Согласен. VS Code юзаю в ембеде 4 года. Сильно хуже по дебагу, в отличии от полноценной студии.
А также, со временем, старые системы ломаются.
Из-за одного софта долго сидел на Ubuntu 18.04 и постепенно все стало ломаться.
Сначала, новые версии перестали работать из-за поднимания минимальной версии libc - запретил обновления vs code. Расширения продолжили обновляться и работало.
Потом сломалась отладка в питоне - сказал хер с этим и поставил наконец Ubuntu 22.04 и все нужное запускаю через докер.
Еще раз обновилось - сломалась удаленная отладка по ssh на машинах с Ubuntu 18.04! А там уже железка и обновится натуральный геморрой. Особенно, на куче машин.
Printf отладка входит в чат...
Есть vs-code, который абсолютно также умеет отлаживать, но не привязан в платформе или компиляторам
А вы когда нибудь пробовали загружать в vscode более менее большой проект?
Не пробуйте - оно не для слабонервных ;)
Я не люблю auto везде, допускаю только когда тип и так написан в этой строке, но ваш аргумент против него выглядит нелепо. Да, может быть и можно теоретически измерить замедление, только потом инстанциирование пары шаблонов займёт в 100 раз больше времени и вы даже не заметите выигрыша. Чтобы auto влияло на скорость, проект должен быть вылизан до идеала: ccache, unity build, идеальные инклюды и forward declaration, и тд и тп.
VS - лучший отладчик? GDB скриптуется лучше, и умеет не меньше. С LLDB у меня опыта меньше, но не замечал чтобы он уступал GDB. Что такого умеет студия, что делает её лучшей?
Мне кажется, что от перехода на С++20 геймдев останавливает то же, что и всех остальных - сырость инструментов. Модули в CMake попали недавно, всё ещё не уверен, что полноценно юзабельно. Компиляторы тоже долго тянули с полноценной поддержкой. Сейчас как раз всё есть, так что с небольшой задержкой на инертность и выгребание проблем перейдут и на 20 и на 23. Не забывайте, что С++20 - самое большое изменение со времён 11.
VS при геймдейве и настроенном проекте сокращает уйму времени но своей ценой конечно, тоесть условия таковы что нужна система пускай и с ценой ресурсов, чтобы не отьедала время на рутину настройки инструментов, соотв проект настроенный на ВС, не тратит время на настройку себя, вы просто работаете с кодом, это как никс, тоесть такая ОС, где всё настроено под пользователя, вот игры на таких системах готовых проще творить, чем на системе где постоянно чото отлетает и постоянно чото надо настраивать
там не только вс, еще нужен визуальный отладчик(типо RenderDoc) пайплайна, там смотреть сколько отрисовок
vs это визуальный cl тоесть оптимизированный под винду clang наверно
посмотрите help от cl в консоле например
лучший по причине развитой инфраструктуры. Позволяет навешивать плагины, писать кастомные парсеры через natvis. Есть открытое апи для интеграции своих бряков, да и разработчики сдк поставляют уже готовые решения под студию и её дебагер. А под всё остальное не поставляют, я может и рад попробовать Clion или Eclipse, но как простите там отлаживать плойку, свич или бокс? Бокс вы приниципе ничем другим подебажить не сможете - ибо вендорлок. Плюс интеграция с пиксом, когда можно в PIX сделать дамп текущего кадра, или написать условния при которых он будет генериться, и сразу выйти в дебаггер посмотреть состояние тредов и таких примеров интеграций очень много.
Геймдев большой, конкретными вендорлоками не ограничивается, некоторые на консоли вообще не целятся, а вот работать на маке хотя бы у разраба хотят. Я не спорю, что для некоторых VS - единственный выбор в силу инструментария, но не думаю, что это большинство разрабов. А те, кто хотят кроссалатформенности так вообще специально отказываются от завязки на инструмент, чтобы собираться везде одинаково. И эта сфера скорее ограничена зоопарком платформ и компиляторов, что замедляет переход на новые стандарты.
З.Ы. Считаю VS одной из худших IDE для плюсов на данный момент, пользуюсь только тогда, когда другого выбора нет. VS Code гораздо лучше.
Нет никакой кроссплатформенности в геймдеве.
Да уж, почувствуй себя Воландом, называется.
Он едва самого меня не свел с ума, доказывая мне, что меня нету
Даже если не брать разные локальные велосипеды, коих всё ещё великое множество, есть UE, который кроссплатформеннее некуда, и пишут на нём часто с прицелом более, чем на одну платформу.
И много мобильных игр вы знаете на UE? И какой процент из них успешный?
И при чём тут мобильный геймдев? Изначальный топик про ПК и консоли, там UE замечательно живёт. На мобилках же С++ часто крутится на своих велосипедах у разрабов с макбуками, а не VS на винде, хотя и она часто встречается. Поэтому самый типичный набор платформ: Win, Mac, iOS, Android. Десктопный линукс если и собирается, то его никто не поддерживает, но и этого списка кроссплатформенности за глаза.
ну на каждой системе просто 1 симейком можно собрать, директИкс то только на винде, есть еще Вулкан
например блендер лтс нативно есть в FreeBSD+assimp всё +- игра считайте
что есть в vscode чего нет в vs для отладки c++?
Тут обсуждалось обратное, чем VS лучше, потому что я считаю, что остальные дебаггеры как минимум не хуже. Большую VS я не люблю как IDE, а не только отладчик. Из плюсов VS Code:
Удалённая разработка по SSH. Можно хоть на боевой сервер подключаться, хоть на локальный WSL. В том числе и удалённая отладка.
Поддержка разных языков, хоть Perl, хоть CMake, опять же с отладкой.
Полная кастомизируемость. Возможно по незнанию, но не представляю как в большой студии можно отдебажить питоновский скрипт, который вызывает плюсовый код, да ещё и настроить это на обычный запуск дебаггера, да ещё и из панели тестирования (тест на питоне).
Легковесность, ни на диске, ни в памяти, ни по процу она много не ест.
Реальная кроссплатформенность. Я разрабатывал как линуксовый сервак с винды, так и виндовое приложение на линуксовом десктопе (изврат полный, но возможен). Ну и на маке тоже работает.
Конфигурируемость всего в виде понятных файлов, доступных для ручного редактирования, а не бесконечный поиск пункта в графическом меню. С синхронизацией опций между компами с локальными особенностями.
Есть масса других мелочей, но и этого достаточно. Я воспринимаю IDE как удобную обёртку поверх множества инструментов, которыми и без неё умею пользоваться, а не один единственно верный идеальный супер-инструмент.
У VS Code по сравнению с VS для меня есть один фатальный недостаток - отсутствие Resharper. Стандартное расширение для C++ очень уж тормознутое.
отдебажить питоновский скрипт, который вызывает плюсовый код, да ещё и настроить это на обычный запуск дебаггера, да ещё и из панели тестирования (тест на питоне).
Вроде всё это можно и из большой студии сделать, Mixed mode debugging, кажется, называется, но у меня так и не завелось. С удовольствием почитал бы, как у вас это устроено.
Я использую Clangd для автокомплита и навигации. На больших проектах он может долго индексировать первый раз, но в процессе работы всё моментально, тормозов не замечено. Размер проекта - час компиляции на этом же компьютере, то есть файлов много. С майкрософтовским IntelliSence в VS Code у меня не сложилось. Он путается с включенным unity build, clangd тоже, но ему можно подсунуть другие compile_commands.json, а вот как это сделать студийному - хз.
Полноценный Mixed Mode я так и не завёл, пока не нужно было параллельно 2 дебаггера, когда step in питона проваливается в плюсы, активен был только плюсовый. Тут суть в том, что плагины для pytest, ctest и дебаггера вполне дружат.
1) сочуствю если основное время приходится пользоваться удалённой разработкой или отладкой по ssh, мне благо это максмимум раз в месяц надобно. У стутдии есть плагин VisualGDB, котороый это всё позволяет, но он платный и настраивается не просто.
2) для cmake точно есть отладка в VS (https://www.youtube.com/watch?v=1eVJBEV9NTk) насчет perl хз, я лчино постоянно пользуюсь отладчиком для lua. Ну и опять же плагины к студии в разы мощьнее, но и писать их сложнее.
3) не понял притензии про питон, и питон и его отладка поддерживается из коробки
4) да как бы всё равно сколько оно ест железо копейки стоит, да и в этой борьбе vs code всё равно проиграет vim. На счет большинсва других аргументов в цолом можно тоже подстьваить vim вместо vscode суть аргумента не поменяется как и его актульность только уже в войне vim vs vscode.
5) Мне как тоне не мешает кроссплатформенный код писать на студиии, а пишем мы под много чего, начиная win на x64 и заканчивая qnx на mips.
6) про синхронизация настроек могу согласится, хотя мб в VS тоже это есть но это я не знаю, просто мне обычно там и настраивать то ни чего не нужно кроме пары хоткеев и установки 2 плагинов в этом и прелесть.
Но это все второстепенные аргументы которые вообще ни какой роли в продуктовой разработке не имеют, а вот как в vscode сделать следующее я лично хз:
1) запустить 1 конкретный юнит тест 1 кликом да в целом управлять unit тестами? как это сделано в resharper
2) выполнить find usage который не просто ищет текст, а ещё понимает контекст. Например что это имя мембера в конкретном классе
3) где там CPU profilers? https://www.youtube.com/watch?v=y8zqYfeR23o (для C++ он точно такой же) или профайлер памяти да и в целом функционал хотя бы близко напоминающий Diagnostic Tools из VS?
4) как добавить отслеживаемые переменные или посмотреть стеки потоков?
5) да даже банально раскарсить код в зависимости от контекста, чтоб свободные функции и функции класса имели разный цвет, чтоб члены класса, глобальные переменные, аргументы функции имели разную подсветку. Я этого найти не смог, и не только в vscode, даже в clion хотя казалось бы решарпер от этих же челов.
не говрю уж об окне ошибок компиляции при инстанцирвоании шаблонов или анализ дампов, и таких вещей ещё сотня наверное наберется, которые можно включить, настроить или запрограмировать под себя.
1) Нет необходимости в совчувствии. Удалённая разработка вообще никак не отличается от локальной в VS Code. Код удалённый, отладчик удалённый, но всё выглядит так, что оно у вас на компе. Вся настройка - host и login.
3) Питоновский тест запускается через панельку тестирования, но цепляется плюсовый отладчик к питону или порождённому им процессу.
Вопросы же "как сделать в VS Code" выдают в вас человека, который вообще не пробовал её и не в курсе. Find Usage через LSP даже в vim цепляется. Раскраска через "editor.semanticTokenColorCustomizations" кастомизируется до мельчайших деталей. Разве что плагина профайлера хорошего и правда нет, я всегда пользовался сторонними инструментами.
Реальные проблемы и недостатки у VS Code есть, она не идеальна. Но я и не называл её лучшим отладчиком или IDE для C++. Я считаю, что по возможностям VS, Code, CLion и тд не особо отличаются и это чистейшая вкусовщина. Есть те, кто и в vim очень продуктивно работает, зачем им мешать?
на счёт lsp, честно ровно 1 раз попытался его настроить несколько лет назад, не удалось и забил, как нибудь ещё раз попробую.
editor.semanticTokenColorCustomizations чето выглядит как капец запарная фигня в духе VisualGDB, и чет сильно я сомневаюсь что ей можно объяснить все нюансы adl в c++.
vs code я пользуюсь регулярно только для меня это текстовый редактор чтоб поправить make файл или простой скриптик на питоне или bash, так что кроме быстрого открытия и базовой подсветки синтаксиса я от него ни чего не жду, а ещё схемки в drawio в нем рисую.
вы назавали ее лучше VS, при том приведя аргументы текстового редактора, VS как легковесный редактор текста ужасен, я спорить тут не буду, было бы абсолютной глупостью запускать инстанс студии только ради открытия 1 файлика с кодом или чтоб yaml конфиг поправить. Ровно такая же глупость как пытаться сделать из текстового редактора IDE для промышленной разработки и говорить что это лучшее IDE.
У меня вообще последние время стойкое ощущение что большинство разрабов перестали понимать что такое IDE и в чем они отличаются от текстовых редакторов с плагинами. Так что нет VS и Code это совершенно не одно и тоже. Clion и VS да, они оба не являются текстовыми редакторами и их хотя бы можно релевантно сравнивать.
Есть те, кто и в vim очень продуктивно работает
вот опять я отхвачу минусы в карму, но да черт с ней. Вот пока они молча сидят и нажимаю кнопки со скоростью машинистки ноль к ним вопросов, но они же начинаю вылезать, убеждать всех какие они крутые, какие "не vim" пользователи говноеды и вообще недопрограммисты и вроде бы фиг с ними взрослые дяди сами разберутся чем им пользоваться но есть и неофиты которые могут взять и поверить в эту чушь, а тебе с ними потом работать и выслушивать как они офигенно настроили свой редактор вместо того чтоб задачами заниматься.
editor.semanticTokenColorCustomizations скорее всего вам и не нужно, это самый тонкий и сложный инструмент. Можно найти готовую цветовую схему на ваш вкус, если ваши требования хоть сколько-то популярны.
большинство разрабов перестали понимать что такое IDE и в чем они отличаются от текстовых редакторов
Вы очень точно уловили суть, я согласен с этим на 100%, но, кажется, интерпретации у нас явно разные. Моя в том, что ничего сложнее текстового редактора с парой плагинов и не нужно. Это понятный и прозрачный инструмент, с которым понятно, что делать, когда что-то идёт не так. А многие фичи большой IDE оказываются просто не нужны. Чем больше она делает за меня "сама", тем меньше гибкости в нестандартных ситуациях.
Несомненно у больших IDE есть своя ниша и свои пользователи, просто это не 100% программистов и не уверен, что даже 50.
Про это Джон Кармак отлично высказался в интервью Фридману - gdb и остальные консольные поделки не предназначены и не удобны для отладки. Как и WinDbg это монстр которого запускают только совсем уж в запущенных случаях. Для ежедневной постоянной отладки оно бесполезно.
Уже давно есть DAP ( debug adapter protocol) через который можно сделать удобный интерфейс для gdb и lldb. Используется в VSCode и прочих редакторах.
Успешно использую данный функционал для ежедневной отладки.
Интерфейс-то есть, вот только что-то никто ничего и близкого по функциональности и удобству к дебаггеру VS так и не сделал.
А линукс-сообщество для которого это по сути и важно, давно привыкло дебажиться printf'ами и делать ничего не планирует...
Вы несколько раз в разных ветках написали, что по функционалу не близко, но можете добавить конкретики? Базовую пошаговую отладку, в том числе визуальную, с отображением значений и брякпоинтами умеют все. К GDB я дописывал плагины для отображения стека, в том числе асинхронного, всевозможных украшательств типа pretty print, скриптовал его изнутри и снаружи для поиска по памяти. Каких фич в нём нет, которые так круты в VS? Я пока увидел только упоминание кастомных профайлеров для конкретных движков или библиотек.
Ну например корректное отображение содержимого стандартных контейнеров, conditional breakpoints, удаленная отладка. Понятно что в целом инструмент мощный, расширяемый и можно дописать что угодно. Вот только это нужно дописывать и/или продираться сквозь чудовищный консольный интерфейс,а в студии все прекрасно работает из коробки.
Простите, но все эти фичи есть. Аргумент про удобно работает в обе стороны. Я привык к GDB, когда мне нужно работать в VS я тоже страдаю и не могу разобраться. И большой плюс консоли в данном случае в том, что текстовые заклинания копипастятся и легко кастомизируются. При этом всё простое можно делать чисто в GUI.
Есть-то они может и есть, вот только придется пол-интернета перерыть чтобы найти что кто-то уже написал скрипт который позволит отображать те-же контейнеры. И не факт что на именно твоей машине оно заведется.
GUI не просто так придумали как развитие интерфейсов. Консоль может быть удобна тем кто привык, но нормальный GUI - интуитивен, хотя, соглашусь что вкусовщина.
ну GDB отьедает человеко-ресурс(тоесть это напряг когда много кода и пишем какую-то штуку принципиальную), вот пример, есть сцена есть обьекты на ней, есть код и допустим там логическая ошибка, человек устал думал об этом ну утомился, и вот от одной мысли что и отладка геморная как-то не проще становится, там с каждым новым погружением реализаций, понимаешь что в системе должно быть всё чотко, потомучто там внимание всё на этом коде, который сейчас реализовываешь
на старте да когда мало кода, всё легко и просто, при уточнении реализаций и прочее такого рода, появляется сложность типо уже кода много, и гдб уже не удобно, даже вс код поудобнее, ну а вс, просто поставил точку останова и он тебе всё показал своим интерфейсом
cmake тоже напрягает если проект на настройку на платформы, соотв, оно всё то вроде про удобство, но надо и там потратить время сосредоточиться и тут
Кондишенал бряки невероятно медленные. Если вам надо один раз то да удобно, но если в цикле намного полезнее в коде написать иф с условиями и там уже обычную бряку. Мало того далеко не все условия отладчик принимает, я за 10 лет так и не вкурил каким свойствам должно удовлетворять выражение в кондишене. В общем кондишенал бряки сильно переоценены. Чем я действительно пользовался с большим удовольствием так это профайлер. Он сэкономил огромную кучу времени, хотя полностью не заменяет точечное измерение времени, как и любой сэмплинг профайлер.
У меня есть опыт сравнения дебагера из вс кода ллдб и мракософтлвского. Вс код конечно кхм кхм скажем курит в сторонке по сравнению со студией. Например я много дебажил эскуэл кверики. Так получается что скул это довольно большие строки. Казалось бы в чем сложность показать всю строку целиком в дебагере в 2024 году? Оказывается большая сложность. Казалось бы почему, так сложно сделать так чтобы точка остановки срабатывала именно в моем файле, а не во всех с таким же именем файла? А что насчёт дебаг май код онли? В общем студия безусловно впереди планеты всей, но не за счет каких то килер фич в дебагере, а за счёт правильного гуя вокруг дебагера.
вот эти дапы надо настраивать, сюда еще прибавляем симейк, и если мы не на движке уйма времени на настройку уходит ) а хочется иногда чтоб само )
GDB руками использовать - конечно дичь, но в комбинации с какой-нибудь годной IDE (вроде QtCreator) он вполне сносно работает.
к сожалению, очень много "общего текста" без конкретики C++17, C++20 и ТП...
а если по времени компиляции, то Дело спасает Системый подход! но в хаосе игродева он невозможен. точка.
ЗЫ если у вас мало Хаоса, то хотя бы:
не включайте не нужные хедеры.
целенаправленно и системно используйте интерфейсы - они скрывают от компилятора требуху реализации и не требуют не нужных хедеров.
используйте unity build.
ЗЗЫ unity build - это когда вместо десятка файлов src\*.cpp билдят всего один src\unity\build.cpp:
#include "../assert.cpp"
#include "../blob.cpp"
#include "../blob_map.cpp"
#include "../dir.cpp"
#include "../exception.cpp"
#include "../fd_file.cpp"
#include "../mem_hash.cpp"
#include "../mem_pool.cpp"
#include "../off_pool.cpp"
#include "../rdwr.cpp"
#include "../text.cpp"
#include "../tx_buf.cpp"вот код и сама статья: https://ders.by/cpp/deque/deque.html
А в чём профит от unity build? При разработке скорость только снизится, для компиляции может понадобиться существенно больше памяти, амальгамация для оптимизации размера в геймдеве некритична, а избежать трансляции хедеров на каждый юнит можно прекомпилированными хедерами.
Нужно использовать столько срр файлов, сколько процессоров на сборочной машине :)
А если N-1 из них компилируются минуту, а один - два часа?
А разбить этого большого медведя на множество маленьких медвежат не судьба?
Наверное можно, но надо прикладывать усилия. А если у нас зоопарк сборочных машин с разным число ядер - для каждой переразбивать по своему?
Я к этому не притрагивался, но CMake с 2019 предлагает какое-то автоматическое разбиение:
BATCH When in this mode CMake determines which files are grouped together. The UNITY_BUILD_BATCH_SIZE property controls the upper limit on how many sources can be combined per unity source file
Я даже не знаю, что теперь забавнее - мой пост или ваш.
У нас юнити билд включен по умолчанию, но автоматически отключается для модифицированных файлов (юзаем перфорс). Очень удобно. Скорость сборки вообще не проблема после первого прогона. FastBuild сверху. И ещё Live++.
Просто надо понимать что настройка удобного окружения для конкретного си++ проекта это несколько сложнее, чем просто запустить инсталлятор и прокликать «далее» несколько раз.
А сколько лет вы в геймдеве уже работаете?
Выглядит так, что улучшится скорее производительность (но тот же эффект даст и LTO). Если хочется сэкономить на многократном парсинге заголовков - в "старых" плюсах есть precompiled headers, в C++ 20 модули (по этому рассказу Владимирова сложилось впечатление, что сами по себе они уже вполне готовы для использования в боевых условиях, но миксовать их с legacy несколько проблематично).
модули классно, но если код на вулкане и пользуемся переносным кодом, с std на модуль на разных платформах что-то надо делать(поидее кланг собрать, но я не уверен - не решился собирать, вот у меня щас не доступны модули - не смогу стд закинуть модулем), а на винде вроде достаточно визуалку обновить, она вроде тянет обнову компилятора
можно сделать документацию для оборачиваемых сущностей в шаблоны и использовать их как нужно это может ускорить время сборки, в 2д я так и сделал, в 3д перестал париться, просто пишите и пускай оно компилируется сколько ей надо лиж бы отношения сущностей были адекватными и на верху было удобно использование
Спасибо за статью! Буду давать на неё ссылку в ответ на вопрос, почему я принципиально не рассматриваю конкретно геймдев.
Довольно показательно, что в HFT (где требования к латентности и штраф за тормоза ещё выше) новые стандарты плюсов как раз очень любят и иногда используют до их финализации.
Про auto — ерунда, потому что компилятору и так надо выводить тип справа хотя бы для того, чтобы проверить, совместим ли он с объявленным типом слева. Плюс, я попробовал простую программу:
template<int N>
int f()
{
if constexpr (N - 1)
{
auto r1 = f<N - 1>();
auto r2 = f<N - 1>() + 1;
return r1 + r2;
}
return 0;
}
int main()
{
f<1024>();
}Минимальное суммарное время десяти компиляций в смысле
time (for i in `seq 1 10`; clang main.cpp -o /dev/null)на моей машине — 875 мс, максимальное — 895 мс, среднее — 884 мс. Если заменить auto на int, то минимальное будет 869 мс, максимальное — 929 мс, среднее — 891 мс. Чё-т так себе ускорение.
Если сделать правую часть интереснее (например,
auto r1 = f<N - 1>() + 0.5;
auto r2 = f<N - 1>() + 0.7;чтобы компилятору пришлось сделать нетривиальные преобразования типов), то разница между auto и явным указанием double будет уже совсем не в пользу явности: 1002 – 1074 мс для auto и 1020 – 1098 мс для явного указания.
Не переходят на последние версии стандарта по тому, что нет потребности в новых возможностях, которые эти стандарты добавляют. Что косвенно сигнализирует о том, что комитет стандартизации свернул "не туда".
Точнее, свернул не туда с точки зрения геймдева. Но есть и много других точек зрения.
Там некуда уже сворачивать: C++ в тупике, возможности его улучшения без ломки обратной совместимости исчерпаны. Если раньше C++ было сложно изучать, то с новыми стандартами неофиту изучить его практически невозможно
Если раньше C++ было сложно изучать, то с новыми стандартами неофиту изучить его практически невозможно
Фразой "современный C++" можно пугать с момента выхода одноимённой книги Александреску в 2001, хотя некоторые вещи с тех времён стали проще.
За "Си с классами", что ли, сбрасывают с обрыва, как за каждый unsafe-которого-можно-было-избежать в расте?..
Смысл себя мучить, если можно взять язык, в котором очевидные проблемы C++ учтены с самого начала? В том числе те проблемы, которые никогда не будут исправлены в C++ из-за обратной совместимости
Почему мучить? D не хватает хотя бы сетевого эффекта (он будет непопулярен, потому что он непопулярен), Rust отрицает Си-подобность и декларирует, что ради безопасности можно много чем пожертвовать.
Мучения где-то впереди. Государства раньше в языки программирования не лезли, также Rust всё чаще будет более дешёвым выбором для бизнеса.
Скорее всего, что C++20 в MSVC просто теперь требует код совместимый со стандартом.
По этой причине многие проекты не переходят.
Корутины в геймдев вроде как потихоньку пролезают, по крайней мере в сетевую часть на серверах.
Мне из нововведений после C++17 только разве что std::span полезен. Модули - не очень то нужно, да и не реализованы они ещё нормально. Концепты тоже как-то не очень полезны, они лишь немного упрощают (или нет) написание шаблонного кода, который не так чтобы уж часто и много пишется. std::format может кому-то и полезен, но без него вполне можно обойтись.
Думаю, тут проблема в фундаментальном законе убывающей отдачи. Всё, что было действительно полезно, уже добавили в стандарт и с каждым новом стандартном добавляются только несущественные мелочи. Правда есть ещё полезности, которые ещё не добавлены (вроде поддержки сети), но такое сложно стандартизировать (с организационной точки зрения), так что ожидать это в обозримом будущем в стандарте не придётся.
Насчёт концептов я так и не понял. От опытных разработчиков (включая, скажем, @antoshkka ) слышал, что диагностика компиляции на концептах - это боль. Хотя, казалось бы, они должны были сделать более ясной и понятной диагностику компилятора в случаях, когда в шаблон подсовывается что-то не то. Спрашивается - как так вышло и зачем они тогда вообще нужны?
У нас пока C++ 17, так что в боевых условиях не пробовал.
Про концепты советую почитать блог
https://akrzemi1.wordpress.com/2021/06/03/decent-concepts/
Там узнаете почему A&&B это хорошо , а A||B делать не надо.
Ну и в концептах A&&B означает совсем не то же самое что а шаблонах A&&B.
У меня более высокоуровневый вопрос - какую задачу решают концепты в языке C++?
Задачу описания по-человечески семантических свойств шаблонных аргументов.
Просто для того чтобы оно было? Так это значит - просто потратить лишнее время на это человеческое описание.
Для того чтобы эти свойства проверялись во время компиляции компилятором, где возможно, а не тестами или рантаймовыми if'ами.
просто потратить лишнее время
Можно сразу в языки с динамической типизацией пойти, там можно на именах типов сэкономить ещё.
Компилятор и так проверит и выдаст ошибку в конкретном месте кода, где переданный в шаблонных аргументах параметр не подходит.
Обычные шаблоны типизированы по-утиному. Если синтаксис не нарушен и такая операция возможна, то всё компилируется, семантика не проверяется (потому что невозможно). А чтобы проверялась сейчас есть срань с бесконечными наборами enable_if и void_t.
Простой пример: то, что у меня скомпилировалось (T t, U u) { t == u; } не значит, что у меня код правильный, ведь мне нужны были, скажем, только целые числа, но сюда можно запихнуть строки, контейнеры, свои классы, да и вообще что угодно, для чего перегружен оператор==. Т.е. мне нужно будет дописать enable_if<is_integral..., и чем сложнее, тем больше. Синтаксис requires сильно проще.
Спасибо - соглашусь, что случаи, когда код компилируется, но семантика нарушена, есть. Вопрос, до какой степени концепты помогают (подозреваю, скажем, что провалидировать компаратор они не смогут) и каков процент случаев в реальной жизни, когда ошибка не выявляется при обычной подстановке в шаблонах, но вылезает с концептами.
у меня скомпилировалось (T t, U u) { t == u; } не значит, что у меня код правильный, ведь мне нужны были, скажем, только целые числа
Конкретно здесь не вижу проблем со строками, но верю, что может быть код с t + u, который со строками скомпилируется, но из за разной семантики приведёт к странным ошибкам - так что да, польза есть.
На самом деле моё брюзжание относится скорее не к самим концептам, а к реализации в компиляторах - не понимаю, почему нельзя кроме прочего ещё и упростить дианостику при ошибках. Конечно, ответ на это простой - исходники есть, сходи и поправь - но лениво, некогда и т.д. и т.п.
и каков процент случаев в реальной жизни, когда ошибка не выявляется при обычной подстановке в шаблонах, но вылезает с концептами
Теоретически, скорее всего, 0.
На практике же есть моменты:
писать правильное нетривиальное sfinae для сгенерированных компилятором функций-членов, скорее всего, просто не будут, если под рукой нет прошаренного шаблонщика. С концептами сильно проще
partial ordering. Обычные шаблоны тут работают только на простых случаях (типа выбор между T, T*, const T перегрузками), выбор же более специализированных ограничений из коробки есть только на концептах:
template <class T, std::enable_if_t<std::is_arithmetic_v<T>, int> = 0>
void foo(const T& t) { }
template <class T, std::enable_if_t<std::is_integral_v<T>, int> = 0>
void foo(const T& t) { }
template<typename T>
concept arithmetic = std::integral<T> && std::floating_point<T>; // тоже самое, что и std::is_arithmetic
void bar(const std::integral auto t) { }
void bar(const arithmetic auto t) { }
int main()
{
bar(5); // это компилируется
foo(5); // а это нет
}Без них либо выкидывать ограничения, либо писать воркэраунды, в которых можно наделать ошибок.
Для того чтобы эти свойства проверялись во время компиляции компилятором, где возможно, а не тестами или рантаймовыми if'ами.
Концепты заведомо не могут проверять никакие семантические свойства (вроде a + b = b + a, что обычно понимают под семантикой). Для этого нужны завтипы, а их в C++ нет.
Концепты помогают с сообщениями об ошибках в темплейтном коде и с выбором конкретной перегрузки функции. Всё.
что обычно понимают под семантикой
Semantics (какая шутка, извините, не удержался). Но что-то типа { op(T1, T2) } -> std::convertible_to<T3>; же уже и не синтаксическое свойство, а если и не семантическое, то что тогда?
Вот кстати здесь вижу
template <typename T>
concept Addable =
std::regular<T> &&
requires(T x, T y) {
{ x += y } -> std::same_as<T&>;
{ x + y } -> std::convertible_to<T>;
/* axiom */ (x + y) == (y + x);
/* axiom */ (x + y) == (x += y);
};
template <Addable T>
T sum(T a, T b);
template <Addable T>
requires std::totally_ordered<T>
T sum(T a, T b);Не могу понять, что конкретно и как проверяет строка 7 (первая с /* axiom */). Только соответствие типов?
Хуже: всего лишь компилируемость этих выражений. Для соответствия типов надо использовать синтаксис с { ... } ->.
В оригинальном пропозале на концепты из нулевых было понятие аксиом (откуда и закомментированная часть), но даже их компилятор не проверял. Это были именно аксиомы, а не теоремы.
Понимаю, что для произвольного кода за конечное время коммутативность в принципе нельзя проверить ) Но хотя бы на типы надеялся.
Понимаю, что для произвольного кода за конечное время коммутативность в принципе нельзя проверить )
За конечное время нельзя автоматически доказать. Проверить доказательство — можно.
Но для этого, да, нужны зависимые типы.
Даже не представляю, как описывать доказательство, если код более-менее нетривальный (скажем, сравниваются два поддерева на файловой системе, операция + соответствует bind из plan 9).
Тут проблема не в том, что код сложный, а в том, что код явно завязан на внешний мир. И тут есть варианты — либо делать модель файловой системы и доказывать все свойства на ней (и проверять её соответствие реальной ФС через какой-нибудь квикчек), либо формализовывать всю ОС и экстрагировать из этого формализма реализацию (доверяя компилятору, но вы ему и так всегда доверяете), например.
Вы о том, что можно сделать только концептами но нельзя по другому ?
В принципе всё можно и без них, но иногда это так сложно, что проще даже не браться.
Скажем, std::ranges полноценно без концептов сделать было слишком сложно.
Код с requires и concept можно заменить на enable_if , но иногда выходит слишком длинная писанина в которой легко ошибиться.
Банальный пример enable_if<is_same_v<T,int> && is_same<U, int>_v>
Легко забыть, что надо писать на самом деле enable_if<conjunction_v<is_same_v<T,int>, is_same<U, int>_v>>
В концептах мы просто можем писать обычно concept A = same_as<T,int> && same_as<U, int>.
Добавлю, что C++20 это не только концепты.
От опытных разработчиков (включая, скажем, @antoshkka ) слышал, что диагностика компиляции на концептах - это боль.
Боль по сравнению со специально написаным человекочитаемым static_assert в котором указано как исправить проблему.
Если сравнивать с альтернативой в виде std::enable_if, то концепты лучше.
самое читаемое для меня покачто это свитч пускай и на 500 строк зато читаемо )
ах да в текстовый редактор тоже может быть в шейдерах там тоже свитч нужен, в сложных ситуациях со строками я предпочту читаемый аналог чем не читаемый, но рабочий
хотя идея крутая constraints
Спасибо за пояснение! Просто неделю назад на C++ Russia про диагностику с концептами вы очень выразительно высказались ) И Руслан (который сюда пишет) тоже говорил, что по крайней мере ему обычные ошибки с темплейтами читать проще, чем после концептов.
с++26 обещает быть бомбой по круче 11. Рефлексия, возможно экзекутеры, возможно контракты, ну и дофига по меньше. Я думаю ВС 28 принесет с собой этот стандарт и в игрострой. Я вот решил завязывать с плюсами ибо бесконечные УБ в коде я могу фиксить, а вот бесконечные споры на ревью с коллегами о том, что здесь уб нет иди кури бамбук - меня уже утомили окончательно. Судя по статье, в игрострое на меня бы смотрели только с улыбкой и не долго. Мне осталась неделя на плюсах и - я свобоодееен, словно птиица в небеесааах. Ну а всем игростроевцем я желаю, чтобы вендоры своевременно обновляли сдк, тулзы не стояли на месте, компиляторы пофиксили все баги, а стл стал быстрым. И самое главное, что бы начальник смотрел на вас с улыбкой пореже.
Ну, рефлексия, имхо, это последнее, что нужно игроделам.
Рефлексия нужна всем. Смотреть на неё можно хотя бы как на отлов заметной доли багов ещё на этапе компиляции
так рефлексия не рантайм, а компайл тайм
ну и пока как я понял кроме как упрощения написаний сериализаторов ни чего сложного там не сделать, т.е ни какой кодогенерации без макросов мы все ещё не увидем в обозримом будующем.
Рефлексия — это больше никаких псевдозначений COUNT в enum-ах. Я прям жду не дождусь дня, когда она станет доступна.
Почему игродев остается на С++17
А вы перестали пить коньяк по утрам? Unreal Engine начиная с версии 5.2 перешёл на C++20, например.
Эм, ну мы тоже билды на плойку отправляем с -std=c++2a, потому что того требует сертификация. В принципе это все, что используется из 20 стандарта :) И да, сборка медленнее почти на две минуты 17, против 15
я пытался сделать анимации на С, и это пожосче С++, лучше мириться с С++, он упрощает многие моменты ), может когда-нибудь отодвину эту дикую масштабируемость кода и сделаю нечитаемую кодовую анимацию, но пока вижу что я не готов )
поэтому с++23/с++26 однозначно )
даже текстовый редактор понятнее на java чем разобраться в анимациях ))
const auto end = m_size; // 0.000062s <<<<<<<<<<<
То есть 100 тыщ auto увеличат время компиляции на одну секунду? посмотрел на вас с улыбкой
тут каждый говорит про свой юзкейс ) там всё равно евристика опыта, если работает с авто без авто, если код работает производительно то всё это обсуждение из разряда какой фломастер ярче ) да и потом в 3д много ноу-хау на проектах я уверен, шаг влево вправо уже принципиальная реализация, которая что-то решает
После пары первых абзацев перестал понимать, о чем речь Т.Т
Не понимаю почему вообще в таких статьях речь идёт о поиске какого-то одного убер-языка для написания всего. Современные системы позволяют использование в одном проекте кроссплатформенного кода написанного на разных языках. Буквально где что вам удобно то и можно применять.
Конкретно: игроделы на Godot вообще могут не знать C++, хотя, очевидно, используют его в своём проекте.
Так на Godot нет ни одной качественной игры в техническом плане
А как же Sonic Colors Ultimate?
Посмотрел на игру, посмотрел на инфу действительно ли игра разработана на Godot
Для Godot игра выглядит слишком хорошо, на Вики по игре пишут что в разработке было задействовано 3 движка включая Godot с ссылками на источники
Вот ссылка https://sonic.fandom.com/wiki/Sonic_Colors:_Ultimate
Это движки оригинальной игры и консольных версий, ПК-переиздание Ultimate на Годоте, можно глянуть Википедию.
Хорошо-то как, настоящая статья с реальным опытом, а не голые тезисы от ChatGPT 👍
Про Visual Studio соглашусь, даёт великолепный опыт разработки и отладки. Я думаю в этом в т.ч. секрет популярности VS Code: потихоньку впитывает лучшее от "старшего брата"
gdb нужен когда на сервере софтина раком встаёт раз в полгода и нужно к ней после этого подключиться чтобы понять в чём же там дело
как обычно, все бурлит не по теме и не видно конкретики... ну окай, я немножко наброшу.
в C++98 у нас было:
template<class InputIt, class T>
InputIt find(InputIt first, InputIt last, const T& value);а в C++20 мы наконец-то обрели:
template<
std::ranges::input_range Rg,
typename T,
typename Proj = std::identity
>
requires std::indirect_binary_predicate<
std::ranges::equal_to,
std::projected<
std::ranges::iterator_t<Rg>,
Proj
>,
const T*
>
constexpr std::ranges::borrowed_iterator_t<Rg> find(
Rg&& rg,
const T& value,
Proj proj = {}
);во что превратился любимый наш сердцу find()? в Чудовищное Говно!
ЗЫ как жить без каки: https://ders.by/cpp/norefs/norefs.html
Да, ведь настоящий программист пишет find, а не использует их. И простота написания find, конечно, важнее простоты его использования, равно как и мощности второго варианта (а вы почему-то случайно или намеренно сравниваете ranges::find с std::find, а не find_if). Писать
const Person& get_person(const PersonsManager& mgr, const std::string& name)
{
// Person всегда есть, `*` норм
return *std::ranges::find(mgr.GetPersons(), name, &Person::name);
}никак нельзя — там же сложные конь-цепты, прожекции какие-то. Я на плюсах код пришёл писать или психологией какой-то заниматься с прожекциями?
Зато вот нет никаких проблем писать в C++98-стиле
struct PersonNameCmp
{
std::string name;
explicit PersonNameCmp(const std::string& name)
: name(name)
{
}
bool operator()(const Person& p) const
{
return p.name == name;
}
};
const Person& get_person(const PersonsManager& mgr, const std::string& name)
{
// Person всегда есть, `*` норм
return *std::find_if(mgr.GetPersons().begin(), mgr.GetPersons().end(), PersonNameCmp(name));
}Ой тут соседний васян отрефакторил GetPersons() который теперь возвращает по значению а не ссылке теперь баг ой ой ой UB рантайм крэш в лучшем случае, надо срочно переписать в три ночи звонок с продакшена на
int person_idx(const PersonsManager& mgr, const std::string& name)
{
const std::vector<Person>& persons = mgr.GetPersons();
return *std::find_if(persons.begin(), persons.end(), PersonNameCmp(name));
}
А почему при auto замедляется время компиляции? По логике, без авто должно быть больше. Компилятор должен вычислить тип справа, вычислить тип слева и сравнить. С auto компилятору достаточно только вычислить тип справа и присвоить этот тип токену-переменной слева.
На данный момент Visual Studio - лучший отладчик C++ в мире
Извините, конечно, - мне бы очень не хотелось начинать это.
Но как в этом отладчике сделать нормальный conditional breakpoint? Любой вызов метода он считает за side effects.
Если знаете ответ - буду благодарен, это ОЧЕНЬ упростит мою работу.
А так - пока что gdb лучший :)
И как посмотреть внутренности std::stack?
Приходится стэк временно превращать в вектор.
стэк это адаптор. Т.е. там итак внутри используется std::vector или std::deque.
Посмотреть его не должно быть проблем ни в VS дебаггере ни в gdb.
Другое дело Qt типы... Это просто ад для дебагинга.
К основным типам вроде вектора, строк есть .natvis для VS. Но к каким-то более редким приходится копаться в самую глубь дерева наследования, пока не найдешь этот d
еще лучше если либа с открытым исходным кодом, свободной лицензией и без обязательного указания авторства.
Ну и разработка игр — одна из немногих отраслей разработки, где есть кредитсы, и даже рядовой программист будет указан в титрах игры
То есть если вставил либу в проект, то попал в титры, а если написал либу, то нет?
Основная причина, почему 17 а не 20 - поддержка стандарта компиляторами в кроссплатформе. std::range::view хороши, но половина компиляторов его не поддерживало, вторая половина не поддерживает другую половину нового стандарта в итоге 17 как наибольший остров стабильности на текущий момент, ибо последующие версии то там то сям имею сноски про partial support. Да и алгоритмы в либах ещё не причёсаны, хотя немало стандартной библиотеки превратилось в constexpr/consteval. Ну а считать наносекунды на дедукцию типов, когда в худшем случае там дай бог сотня переменных на юнит трансляции ну такой себе простор для оптимизации скорости сборки. Я б понял расчёт шаблонных параметров с variadic template parameters, но это вроде тоже не сказать чтобы сильно влияет на сборку. Обычно боль где-то с резолвингом имён функций происходит, когда кандидатов набирается немало.
AI не изменил кодинг в геймдеве вообще никак? Удивительно. В "энтерпрайзе" он не то чтобы отменил кастомные либы, но их теперь и делать "не хочется": свою супер-библиотеку решающую что-либо "лучше" стандартной, если о ней не знает ChatGPT, стыдно даже кому-либо показать.
На удивление изменил и в лучшую сторону, мне теперь не приходится перерывать сорцы в поисках какого-то хорошего решения, а можно спросить местную аишку где это лежит и оперативно подтянуть. Ну и можно натравить аишку на кодревью, тоже показывает потенциально проблемные места. Работает где-то на уровне мидла недавно пришедшего на проекта, стандарт знает и что где лежит тоже, но вот с починкой и написанием чего-то сложнее обычной сортировки уже проблемы.
В целом я согласен с позицией автора.
Единственное, что меня в плюсах всегда смущало, это скорее не скорость компиляции, а скорость разработки.
На дворе 2025 год, стандарта около этого года, я так понимаю нет, либо есть, но не реализованы фичи в большинстве компиляторов, сборщиков и тому подобное.
И, если посмотреть как развиваются другие языки, то то, что плюсы медленно развиваются, скорее не из-за самого языка, а из-за чего-то другого. Преполагаю, что стандарт (спека) плюсов отдельно публикуется от компилятора.
Поправьте, если не прав.
Так же против плюсов ничего не имею, это часть на случай, если кто-то увидел, что я ущемляю их любимый язык. Нет, я этого не делаю, я отношусь к этому языку точно так же как и к всем остальным.
Преполагаю, что стандарт (спека) плюсов отдельно публикуется от компилятора.
Естественно - стандарт разрабатывается комитетом, а каждый из компиляторов - соответствующей командой разработчиков. Соответственно и уровень поддержки последних стандартов языка в разных компиляторах разный.
Насколько я знаю, уже много лет как во-первых, разработчики основных компиляторов участвуют в разработке стандарта, и могут попросить доработать предложение, если его тяжело реализовать, во-вторых, предложение принимают только после того, как хотя бы в одном из компиляторов оно реализовано.
Другое дело, что для больших и сложных фич в итоге всё равно получается, что на момент публикации стандарта они частично реализованы только в одном компиляторе, частично только в другом, и ни на одном компиляторе невозможно этим нормально пользоваться.
Тема C++17 не раскрыта. Пост про трудовые будни геймдева, и про плюсы тут только, что долго собирается. Пишите на голом Си.
Почему игродев остается на С++17