А это просто совпадение, что скриншоты ну ооочень похожи например на это? rustrain3d.ru/sites/default/files/ed4m_pult_03.jpg Особенно рельсы. Плюс стиль изложения немного похож например на это: rustrain3d.ru/ru/main-train-simulators Да и описанную архитектуру (клиент-сервер, железки, отказ от игровых движков в пользу просто графического, Linux, Qt) я где-то уже видел… Вот честно — вы вдохновлялись рустрейновскими тренажёрами, или просто так совпало, что пошли почти тем же путем, только на несколько лет позже?
UPD. На всякий случай — речь про копирование кода не идёт, просто в целом всё очень похоже.
И где видно что количество операций сложения, умножения и обращений к памяти уменьшилось или хотя бы сравнение по производительности на тестовых примерах.
На самом деле — дуальные кватернионы немного "дороже" по операциям, чем просто пара "вектор переноса + обычный кватернион". Главное их преимущество — почти полное отсутствие артефактов при скиннинге в местах, где на вершины влияет более одной кости. В видео приведенном в статье про это рассказывается с 0:55. И там кстати видно, что интерполяция на дуальных кватернионов работает чуть медленнее (~200 FPS) чем "обычный" метод (~270 FPS)
Можно, но тогда вы лишаете себя одной из киллер-фич C++ — статического "полиморфизма". Плюс выбор готовых решений становится еще меньше, а значит велосипедов придется писать еще больше. Ну и в принципе то, что вы предлагаете — это писать на диалекте "C с классами", а в этом случае имхо тогда уж лучше писать на обычном C более-менее свежего стандарта (хотя бы C99) — выигрыш в скорости компиляции еще больше (в разы!) и можно использовать фичи недоступные в плюсах (designated initializers просто бомба). При этом никто не мешает продолжать писать в ООП стиле — в качестве примера можно посмотреть например на libuv.
Для начала небольшой disclaimer — всерьез для этих целей C++ я в принципе никогда не рассматривал. Более того, основной мой опыт — это всякая математика (как раз на плюсах), а веб-сервисы — до недавнего времени только в рамках хобби-проектов для самообразования. Так вот, если в рамках этого опыта сравнить какой-нибудь express в ноде, aiohttp в питоне и actix-web в расте — то везде все выглядит достаточно просто и понятно. Причем все эти проекты достаточно хорошо поддерживаются, имеют хорошую документацию и большое коммьюнити. Если же посмотреть в этом плане на C++ — то первое, что находится для HTTP — это boost beast, и я допускаю, что он позволяет писать сложные и эффективные сервера, но первый взгляд на их API оставил впечатление чего-то дико неудобного и переусложненного. А это и крутая кривая обучения, и намного больше шансов отстрелить себе что-то в процессе использования. Еще есть pion (который в составе splunk) — опять же смотрел очень поверхностно, но впечатления — API выглядит более человечным, но последний коммит на гитхабе в 2016 году и с документацией беда.
Ну и наконец — месяца 3 назад узнал про restinio (насколько я понимаю — это вклад вашей компании в open source), API выглядит действительно человеческим, и довольно неплохая документация. Немного напрягает очень маленькое комьюнити вокруг проекта, но вы вроде прикладываете усилия к популяризации этого проекта, в чем я вам искренне желаю удачи и очень надеюсь, что у вас получится его «раскрутить». Если бы сейчас у меня была задача сделать сервис на C++, то вполне вероятно взял бы как раз restinio.
Однако все выше написанное не отменяет того, что:
— для веба в C++ инструментов гораздо меньше, чем в других языках (то, что вам пришлось написать собственный HTTP фреймворк только подтверждает это)
— C++ имхо лидирует по легкости получения undefined behavior и отстрела жизненно важных органов
— время компиляции (особенно если активно используются шаблоны) — это боль
ser-mk в общем-то уже ответил примерно то же, что я хотел написать, могу только добавить что «тонкие настройки компилятора» — еще как есть, включая замену компилятора на любой другой. И все благодаря тому, что система сборки отдельно, IDE отдельно. Просто это не флажками в GUI, а «кодом» в CMake, и это реально удобно, особенно когда нужно сделать что-то хитровывернутое.
А CI у вас есть? И если да — настройки сборки там из sln берутся, или какими-то отдельными средствами? Ну и я бы не сказал, что отдельно CMake, отдельно IDE — это плохо, для меня это скорее плюс. В общем, видимо на вкус и цвет…
Да, недостаток выбора библиотек имеется — язык очень молодой. Но это постепенно исправляется. Кроме того, частично помогает то, что можно линковаться с существующими С и С++ либами (да, официально поддерживается только C API, однако ж например биндинги для rocksdb есть, хотя это и плюсовый проект).
> eigen
Это очень классная либа, я бы сказал — уникальная. Но у нее есть три фатальных недостатка (по крайней мере, если говорить о той части, где всякие SVD и SparseLLDT):
1) оно очень медленно собирается
2) оно очень медленно работает в дебаге
3) легко выстрелить в ногу, особенно если комбинировать с современными фичами C++ типа auto
По факту — приходилось заворачивать инстанцирование шаблонов внутрь простого C API, компилировать эти объектники всегда с оптимизацией, и в итоге для кода снаружи это выглядело не сильно лучше, чем использовать какой-нибудь MKL.
> И пока нельзя безболезненно начать писать новый проект на расте вместо крестов не думая о том что же делать если биндингов к нужной либе не окажется
Зависит от проекта. Какой-нибудь REST API, который работает с базой и какими-то еще сервисами нафигачить на расте сейчас гораздо легче, чем на плюсах.
Хм, у меня прямо противополжный опыт, подозреваю, что это связано с тем что я в обратной ситуации — лет 5 QtCreator был основным инструментом разработки, а MSVS использовался только когда припрет что-то очень специфичное сделать (типа экспортера для 3dmax).
> работа с ним вылилась в постоянное залезание в дебри для конфигурации настроек, которые в VS настраиваются или из коробки, или одним кликом. Отсутствие нормального понятия «проект»: в VS через solution есть доступ к любым настройкам на вкус и цвет
Отлично все настраивается в CMake, нормально хранится в системе контроля версий и git log при изменениях конфигурации сборки показывает вполне человеческие диффы (как кстати с этим в случае с sln-файлами?). Да, надо знать CMake. Зато не надо помнить в какой из 10 вкладок находится нужная галочка.
> Отладка по сравнению с VS — очень не удобно
Что имеено неудобно? Пошаговая отладка есть, watch есть, точки останова есть. Хоткеи — дело привычки, для меня например MSVS неудобен в этом плане.
> встроенных тулзов типа профилировщика производительноти всего на свете
Тут пожалуй соглашусь, хотя вроде пару лет назад добавили поддержку gprof, так что профилировать все-таки можно. Сам не пользовался, поскольку в проекте была уже куча собственных метрик. Зато активно использовали valgrind (правда это непосредственно к IDE не относится) — в MSVS есть подобные инструменты?
> это был реальный кейс работы над существующим проектом в Qt — и в общем это было не слишком приятно
Возможно дело все же в привычке? Вопросы кстати не риторические — мне правда интересно узнать конкретные кейсы, где MSVS объективно лучше QtCreator.
А можете привести пример того, что было полезного в VS, чего не было в QtCreator? Не для холивара, мне действительно интересно, поскольку есть опыт работы с QtCreator с проектом где-то 500 kLOC и как-то проблем именно связанных с IDE особо не ощущалось.
Вы знаете, я писал на C++ почти 20 лет, из них 17 — коммерческая разработка. В том числе почти 10 лет немного похожий на геймдев проект. Писал как используя шаблонное метапрограммирование, так и ограниченный диалект C с классами. С range v3 упомянутым в статье кстати хорошо знаком и очень жалею, что это до сих пор не в стандарте. А года полтора назад познакомился с растом, пробовал писать на нём несколько мелких хобби проектов, и вот прям не покидает ощущение, что это "C++ done right". И видимо я далеко не один такой.
Попробуйте QtCreator — бесплатный, быстрый, кроссплатформенный, заточенный под C++. И не смотрите, что в названии Qt — этот фреймворк там поддерживается, но не навязывается.
Вырастает. Не всегда конечно, но достаточно часто. И тестов таких обычно можно гораздо меньше писать, чем традиционных — что положительно сказывается на стоимости как разработки, так и поддержки. И краевые случаи ловятся такие, про которые далеко не каждый быстро догадается, если догадается вообще, пока в проде не сломается. В общем, похоже нужна отдельная статья туториал про то, как Вася и Петя писали тесты и код...
Как-то нужно было реализовать построение полигональной модели по некоторой характеристической функции (а функция в свою очередь строилась через облако точек, но речь сейчас не о нем). Задача решается довольно стандартным способом — marching cubes, но по ряду причин на модель накладывались условия непрерывности (не должно быть дырок) и двусвязности (2-manifold, т.е. одно ребро может граничить не более чем с двумя полигонами). А из-за ошибок точности чисел с плавающей точкой (внезапно при определенных условиях a+(b+c) != (a+b)+c) периодически получались дырки. И тупое округление тоже не помогало — дырки только больше становились. А не совсем тупое округление неожиданно периодически приводило к многосвязным поверхностям. И все это было поймано двумя короткими рандомизированными тестами, так и не добравшись до прода.
В глубине одного pet-проекта надо было посчитать среднее арифметическое между двух целых чисел. Ну и разумеется там было (a + b) / 2. И конечно, при рандомизированном тестировании таки сгенерился кейс, при котором a + b словили целочисленное переполнение, которое не вызывало падения само по себе, но дальше в данных шла дикая ересь. И только благодаря этому тесту я узнал, что целочисленное среднее арифметическое правильно считать как a + (b — a) /2 (при условии, что b > a, иначе меняем местами a и b).
UPD. На всякий случай — речь про копирование кода не идёт, просто в целом всё очень похоже.
На самом деле — дуальные кватернионы немного "дороже" по операциям, чем просто пара "вектор переноса + обычный кватернион". Главное их преимущество — почти полное отсутствие артефактов при скиннинге в местах, где на вершины влияет более одной кости. В видео приведенном в статье про это рассказывается с 0:55. И там кстати видно, что интерполяция на дуальных кватернионов работает чуть медленнее (~200 FPS) чем "обычный" метод (~270 FPS)
Можно, но тогда вы лишаете себя одной из киллер-фич C++ — статического "полиморфизма". Плюс выбор готовых решений становится еще меньше, а значит велосипедов придется писать еще больше. Ну и в принципе то, что вы предлагаете — это писать на диалекте "C с классами", а в этом случае имхо тогда уж лучше писать на обычном C более-менее свежего стандарта (хотя бы C99) — выигрыш в скорости компиляции еще больше (в разы!) и можно использовать фичи недоступные в плюсах (designated initializers просто бомба). При этом никто не мешает продолжать писать в ООП стиле — в качестве примера можно посмотреть например на libuv.
Ну и наконец — месяца 3 назад узнал про restinio (насколько я понимаю — это вклад вашей компании в open source), API выглядит действительно человеческим, и довольно неплохая документация. Немного напрягает очень маленькое комьюнити вокруг проекта, но вы вроде прикладываете усилия к популяризации этого проекта, в чем я вам искренне желаю удачи и очень надеюсь, что у вас получится его «раскрутить». Если бы сейчас у меня была задача сделать сервис на C++, то вполне вероятно взял бы как раз restinio.
Однако все выше написанное не отменяет того, что:
— для веба в C++ инструментов гораздо меньше, чем в других языках (то, что вам пришлось написать собственный HTTP фреймворк только подтверждает это)
— C++ имхо лидирует по легкости получения undefined behavior и отстрела жизненно важных органов
— время компиляции (особенно если активно используются шаблоны) — это боль
> eigen
Это очень классная либа, я бы сказал — уникальная. Но у нее есть три фатальных недостатка (по крайней мере, если говорить о той части, где всякие SVD и SparseLLDT):
1) оно очень медленно собирается
2) оно очень медленно работает в дебаге
3) легко выстрелить в ногу, особенно если комбинировать с современными фичами C++ типа auto
По факту — приходилось заворачивать инстанцирование шаблонов внутрь простого C API, компилировать эти объектники всегда с оптимизацией, и в итоге для кода снаружи это выглядело не сильно лучше, чем использовать какой-нибудь MKL.
> И пока нельзя безболезненно начать писать новый проект на расте вместо крестов не думая о том что же делать если биндингов к нужной либе не окажется
Зависит от проекта. Какой-нибудь REST API, который работает с базой и какими-то еще сервисами нафигачить на расте сейчас гораздо легче, чем на плюсах.
> работа с ним вылилась в постоянное залезание в дебри для конфигурации настроек, которые в VS настраиваются или из коробки, или одним кликом. Отсутствие нормального понятия «проект»: в VS через solution есть доступ к любым настройкам на вкус и цвет
Отлично все настраивается в CMake, нормально хранится в системе контроля версий и git log при изменениях конфигурации сборки показывает вполне человеческие диффы (как кстати с этим в случае с sln-файлами?). Да, надо знать CMake. Зато не надо помнить в какой из 10 вкладок находится нужная галочка.
> Отладка по сравнению с VS — очень не удобно
Что имеено неудобно? Пошаговая отладка есть, watch есть, точки останова есть. Хоткеи — дело привычки, для меня например MSVS неудобен в этом плане.
> встроенных тулзов типа профилировщика производительноти всего на свете
Тут пожалуй соглашусь, хотя вроде пару лет назад добавили поддержку gprof, так что профилировать все-таки можно. Сам не пользовался, поскольку в проекте была уже куча собственных метрик. Зато активно использовали valgrind (правда это непосредственно к IDE не относится) — в MSVS есть подобные инструменты?
> это был реальный кейс работы над существующим проектом в Qt — и в общем это было не слишком приятно
Возможно дело все же в привычке? Вопросы кстати не риторические — мне правда интересно узнать конкретные кейсы, где MSVS объективно лучше QtCreator.
deleted, случайно два раза отправилось
А можете привести пример того, что было полезного в VS, чего не было в QtCreator? Не для холивара, мне действительно интересно, поскольку есть опыт работы с QtCreator с проектом где-то 500 kLOC и как-то проблем именно связанных с IDE особо не ощущалось.
Вы знаете, я писал на C++ почти 20 лет, из них 17 — коммерческая разработка. В том числе почти 10 лет немного похожий на геймдев проект. Писал как используя шаблонное метапрограммирование, так и ограниченный диалект C с классами. С range v3 упомянутым в статье кстати хорошо знаком и очень жалею, что это до сих пор не в стандарте. А года полтора назад познакомился с растом, пробовал писать на нём несколько мелких хобби проектов, и вот прям не покидает ощущение, что это "C++ done right". И видимо я далеко не один такой.
Попробуйте QtCreator — бесплатный, быстрый, кроссплатформенный, заточенный под C++. И не смотрите, что в названии Qt — этот фреймворк там поддерживается, но не навязывается.
Отдельное спасибо за идею с самодельным glovebox!
Шарик с авито на елке
А я знаю пример, когда разработчик "въехал" и начал нормально писать на расте за пару недель. До этого он писал на го и скале.
Вырастает. Не всегда конечно, но достаточно часто. И тестов таких обычно можно гораздо меньше писать, чем традиционных — что положительно сказывается на стоимости как разработки, так и поддержки. И краевые случаи ловятся такие, про которые далеко не каждый быстро догадается, если догадается вообще, пока в проде не сломается. В общем, похоже нужна отдельная статья туториал про то, как Вася и Петя писали тесты и код...
Тот, кто сказал покрыть код тестами. Или вообще писать по TDD.
Легко.
Как-то нужно было реализовать построение полигональной модели по некоторой характеристической функции (а функция в свою очередь строилась через облако точек, но речь сейчас не о нем). Задача решается довольно стандартным способом — marching cubes, но по ряду причин на модель накладывались условия непрерывности (не должно быть дырок) и двусвязности (2-manifold, т.е. одно ребро может граничить не более чем с двумя полигонами). А из-за ошибок точности чисел с плавающей точкой (внезапно при определенных условиях a+(b+c) != (a+b)+c) периодически получались дырки. И тупое округление тоже не помогало — дырки только больше становились. А не совсем тупое округление неожиданно периодически приводило к многосвязным поверхностям. И все это было поймано двумя короткими рандомизированными тестами, так и не добравшись до прода.
В глубине одного pet-проекта надо было посчитать среднее арифметическое между двух целых чисел. Ну и разумеется там было (a + b) / 2. И конечно, при рандомизированном тестировании таки сгенерился кейс, при котором a + b словили целочисленное переполнение, которое не вызывало падения само по себе, но дальше в данных шла дикая ересь. И только благодаря этому тесту я узнал, что целочисленное среднее арифметическое правильно считать как a + (b — a) /2 (при условии, что b > a, иначе меняем местами a и b).
И могу продолжать дальше...