Comments 60
стандартного графического фреймворка нет
Прям в std чего-то такого никогда не будет, конечно. А если в более широком смысле, то проект https://github.com/gfx-rs/gfx очень сильно на эту роль пытается претендовать, хотя недавний гигантский рефакторинг всего проекта сильно пошатнул его стабильность.
возможностей по-человечески создавать игры тоже
Не уверен что это значит, но есть надежда что амбициозный проект https://github.com/amethyst/amethyst постепенно таки родит неплохой модульный игровой движок. Работы там, правда, тоже море еще.
Еще для 2д игр есть намного менее амбициозный и простой https://github.com/ggez/ggez (вариация на тему love2d), на котором я свою хобби-игру потихоньку ковыряю.
Постоянно на него облизываюсь, но каждый раз останавливает нужда в ООП.
В этом месте обычно принято говорить про ECS (Entity Component System) и кидать ссылку на доклад Катерины, тем более что речь в статье о разработке игр, где этот подход последние годы получает все больше признания.
Как правильно писал автор — разработчики игр, в основной массе, пользуются Visual Studio.
И вот здесь начинаются проблемы с растом.
Все мои попытки настроить Visual Studio под Раст закончились почти ни чем.
Постоянно вижу восторженные посты о расте, но лично у меня пока совсем не получается насладиться им в силу выше описанной проблемы :(
Visual Studio или Visual Studio Code? Настроить первое под rust — это какая-то безумная идея. :) Вряд ли visual studio будет его когда-нибудь поддерживать.
Лучше, на мой взгляд, развивать IDE-плагин на платформе IntelliJ IDEA. Сейчас этот плагин пилят в том числе и люди из JetBrains, возможно, когда-нибудь оно превратится в полноценную и мощную IDE для rust от JetBrains.
VS в принципе пора выкидывать как из за нацеленности на одну платформу, так и из за закрытости
Попробуйте QtCreator — бесплатный, быстрый, кроссплатформенный, заточенный под C++. И не смотрите, что в названии Qt — этот фреймворк там поддерживается, но не навязывается.
Сорри, что влезаю — я попробовал — VS примерно настолько же мощнее QT Creator, насколько он мощнее блокнота. Да маленьких проектов норм, для больших, да при сложной отладке, да в сложной среде… вообще нет.
А можете привести пример того, что было полезного в VS, чего не было в QtCreator? Не для холивара, мне действительно интересно, поскольку есть опыт работы с QtCreator с проектом где-то 500 kLOC и как-то проблем именно связанных с IDE особо не ощущалось.
Удаленная отладка, поддержка C++/CX, интегрированное тестирование, профайлеры разных видов, подтягивание дебажных символов для виндовых библиотек… Тонкие настройки компилятора, логично работающая система с solutions. И просто "все работает". В QT Creator всегда было ощущение наколеночности и бесконечных костылей.
Удаленная отладка, поддержка C++/CX, интегрированное тестирование, профайлеры разных видов, подтягивание дебажных символов для виндовых библиотек… Тонкие настройки компилятора, логично работающая система с solutions. И просто «все работает». В QT Creator всегда было ощущение наколеночности и бесконечных костылей.
А вы точно с creator работали? Удаленная отладка уже как года 4 точно я пользуюсь. По стандартам ничего не скажу. Тестирование тоже уже появилось, но не пользовался им, как и виндовыми либами.
Тонкие настройки задаются легко через qmake, можно к ним условия применять. Все изменения легко в diff видеть.
И у меня там не просто «все работает», а летает и грузится в миг в отличие от комбайна VS)
Ну и напомните сколько вы отдали за лицензию VS)
Ну вот у меня другой опыт. В VS все как-то едино — и solutions, и настройки, все точно также в гите, но это все в единой системе — а не отдельно IDE, отдельно qmake, отдельно иногда cmake, в итоге каша. Хотя вполне может работать, я охотно верю, но для меня QT Creator — это странная эрзац-VS для QT, не более чем — типа, ну на безрыбье хотя бы так. А если учесть, что VS поддерживает не только C++, и оно бывает тоже надо (хотя бы C#)…
За лицензию VS ни разу не платил — либо пользовался Express Editions (там кое-чего нет, но база вся есть), либо по программе BizSpark получал бесплатно — это очень несложно. Не хачил VS, по-моему, никогда.
deleted, случайно два раза отправилось
Да, это первое субъективное впечатление, не претендующее на полную корректность, но все же это был реальный кейс работы над существующим проектом в Qt — и в общем это было не слишком приятно.
> работа с ним вылилась в постоянное залезание в дебри для конфигурации настроек, которые в VS настраиваются или из коробки, или одним кликом. Отсутствие нормального понятия «проект»: в VS через solution есть доступ к любым настройкам на вкус и цвет
Отлично все настраивается в CMake, нормально хранится в системе контроля версий и git log при изменениях конфигурации сборки показывает вполне человеческие диффы (как кстати с этим в случае с sln-файлами?). Да, надо знать CMake. Зато не надо помнить в какой из 10 вкладок находится нужная галочка.
> Отладка по сравнению с VS — очень не удобно
Что имеено неудобно? Пошаговая отладка есть, watch есть, точки останова есть. Хоткеи — дело привычки, для меня например MSVS неудобен в этом плане.
> встроенных тулзов типа профилировщика производительноти всего на свете
Тут пожалуй соглашусь, хотя вроде пару лет назад добавили поддержку gprof, так что профилировать все-таки можно. Сам не пользовался, поскольку в проекте была уже куча собственных метрик. Зато активно использовали valgrind (правда это непосредственно к IDE не относится) — в MSVS есть подобные инструменты?
> это был реальный кейс работы над существующим проектом в Qt — и в общем это было не слишком приятно
Возможно дело все же в привычке? Вопросы кстати не риторические — мне правда интересно узнать конкретные кейсы, где MSVS объективно лучше QtCreator.
Скорее всего дело по большей части и правда в привычке, у меня часто так. И все же, мне не надо знать CMake, не надо знать флаги gcc, не надо разбираться в новом зоопарке встроенных в IDE технологий, переходя к новому проекту (в идеале) — мне нужно просто кликать мышкой в меню. На вкус и цвет, конечно, но лично меня это сильно привлекает.
Ну другие платформы и не особо то нужны.
Операционная система — это просто инструмент. Если вы пишете кроссплатформенный код, то привязанность к платформе не может быть аргументом против. Закрытость — вообще смешно, особенно учитывая, как Microsoft в последнее время всё открывает.
P.S. Вроде как в VS уже возможна удалённая отладка C++ кода под Linux, но я не пробовал:
docs.microsoft.com/en-us/cpp/linux/deploy-run-and-debug-your-linux-project?view=vs-2017
Настроить первое под rust — это какая-то безумная идея. :) Вряд ли visual studio будет его когда-нибудь поддерживать.
Да, именно VS. Я не из вредности — это, считайте, стандарт де-факто для разработчиков игр.
И поэтому я оставил коментарий выше, в надежде что мне подскажут как подружить VS и Rust. Но, судя по коментариям ниже, вызвал только волну холивора :(
PS. Тот же Python или D ведь получили очень хорошую интеграцию (Python уже прямо из коробки работает).
Нельзя просто так взять и удержаться от упоминания раста в теме по С++.
Набираешь на клавиатуре "С" — все вроде тихо. Набираешь следующим символом "+" — в теме уже десяток апологетов раста говорят что в нем все более лучше чем в плюсах, чисто быстро модно молодежно, в твоей комнате откуда-то появляется мужик со стаканчиком кофе из старбакса и поясняет как неправильно ты жил до изобретения раста и предлагает попробовать, "а там и втянешься".
Такое впечатление что пишущие на плюсах это язычники которых пытаются обратить в новое языковое христианство, рассылая миссионеров повсюду.
</sarcasm>
По мощности форса раст опережает, разве что, котлин.
Согласен с вами, то же и про жабу. Где жаба, там в комментах котлин) я не противник и не хейтер. Я слишком стар для этой хурмы (с)
Только путь в то же время не считают пользователей крестов какими-то ретроградами закрытыми для всего нового.
Когда в тот же раст завезут полноценную поддержку библиотек которыми я пользуюсь (tensorflow, openCV и CatBoost, поначалу), когда завезут нормальную поддержку на embedded и когда для большинства популярных либ появятся хотя бы биндинги — тогда я попробую и оценю все преимущества.
А пока — извольте, я пользуюсь плюсами не потому что дурачок и не понимаю их недостатков, а потому что ничего лучше для моих задач еще не придумали. А раст останется языком для софта с уникальной фишкой «написано на новом и блестящем расте».
Возможно, как прокомментировал Xop, раст и является «С++ done right», но вот только он является им для
мелких хобби проектовИ пока нельзя безболезненно начать писать новый проект на расте вместо крестов не думая о том что же делать если биндингов к нужной либе не окажется, что делать если остальные члены твоей команды не знают этот язык, как доказывать менеджменту что нужно использовать именно новомодный раст когда есть годами проверенные плюсы — он и останется языком для мелких хобби проектов.
Раст может быть очень хорош как язык, но как инструмент разработчика он все еще сырой.
> eigen
Это очень классная либа, я бы сказал — уникальная. Но у нее есть три фатальных недостатка (по крайней мере, если говорить о той части, где всякие SVD и SparseLLDT):
1) оно очень медленно собирается
2) оно очень медленно работает в дебаге
3) легко выстрелить в ногу, особенно если комбинировать с современными фичами C++ типа auto
По факту — приходилось заворачивать инстанцирование шаблонов внутрь простого C API, компилировать эти объектники всегда с оптимизацией, и в итоге для кода снаружи это выглядело не сильно лучше, чем использовать какой-нибудь MKL.
> И пока нельзя безболезненно начать писать новый проект на расте вместо крестов не думая о том что же делать если биндингов к нужной либе не окажется
Зависит от проекта. Какой-нибудь REST API, который работает с базой и какими-то еще сервисами нафигачить на расте сейчас гораздо легче, чем на плюсах.
Какой-нибудь REST API, который работает с базой и какими-то еще сервисами нафигачить на расте сейчас гораздо легче, чем на плюсах.
А какие инструменты для этих целей в C++ вы рассматривали и почему они вам не подходят?
Ну и наконец — месяца 3 назад узнал про restinio (насколько я понимаю — это вклад вашей компании в open source), API выглядит действительно человеческим, и довольно неплохая документация. Немного напрягает очень маленькое комьюнити вокруг проекта, но вы вроде прикладываете усилия к популяризации этого проекта, в чем я вам искренне желаю удачи и очень надеюсь, что у вас получится его «раскрутить». Если бы сейчас у меня была задача сделать сервис на C++, то вполне вероятно взял бы как раз restinio.
Однако все выше написанное не отменяет того, что:
— для веба в C++ инструментов гораздо меньше, чем в других языках (то, что вам пришлось написать собственный HTTP фреймворк только подтверждает это)
— C++ имхо лидирует по легкости получения undefined behavior и отстрела жизненно важных органов
— время компиляции (особенно если активно используются шаблоны) — это боль
Работу с HTTP в C++ можно разделить на две составляющие: открытие HTTP-сервера в своем приложении и выполнение исходящих HTTP-запросов.
С первой составляющей, как раз таки, все не так уж и плохо. Кроме Boost.Beast и RESTinio есть еще, как минимум: Silicon, CROW, Pistache, RestBed, served, C++REST SDK. Есть из чего выбирать.
Проблема здесь в том, что многие C++ники не идут в своих поисках дальше Boost-а. Находят Boost.Beast (или даже примеры самодельных серверов на базе Boost.Asio) и на этом останавливаются. Хотя тот же Boost.Beast он не столько для прикладного разработчика, сколько для написания на его базе более удобных инструментов.
А вот с исходящими HTTP-запросами сложнее. Тут либо Boost.Beast (что непросто), либо старый добрый libcurl (что проще и удобнее, но при наличии опыта). Хотя, если libcurl придется использовать в асинхронном режиме, то там есть с чем поразбираться (мы на эту тему даже серию статей написали, т.к. актуальной информации в Интернете было немного).
Наверное, можно что-то и в других библиотеках найти (вроде что-то было в POCO), но затягивать в проект стороннюю большую библиотеку только ради возможности сделать HTTP POST… Не всем нравится.
Что касается работы с СУБД, то в C++ есть старые, довольно мощные и проверенные временем OTL и SOCI.
то, что вам пришлось написать собственный HTTP фреймворк только подтверждает это
У нас были серьезные требования к асинхронности выполнения запросов. Существовавшие на тот момент инструменты были больше заточены под синхронную работу.
время компиляции (особенно если активно используются шаблоны) — это боль
А если принципиально отказаться от шаблонов и Буста?
Можно, но тогда вы лишаете себя одной из киллер-фич C++ — статического "полиморфизма". Плюс выбор готовых решений становится еще меньше, а значит велосипедов придется писать еще больше. Ну и в принципе то, что вы предлагаете — это писать на диалекте "C с классами", а в этом случае имхо тогда уж лучше писать на обычном C более-менее свежего стандарта (хотя бы C99) — выигрыш в скорости компиляции еще больше (в разы!) и можно использовать фичи недоступные в плюсах (designated initializers просто бомба). При этом никто не мешает продолжать писать в ООП стиле — в качестве примера можно посмотреть например на libuv.
а в этом случае имхо тогда уж лучше писать на обычном C более-менее свежего стандарта
Не лучше. Даже C++ без шаблонов и исключений (как правило, от исключений отказываются даже раньше, чем от шаблонов) выгоднее использовать, чем "чистый C": более строгая типизация, ссылки вместо указателей, пространства имен, auto, constexpr, enum class, нормальное ООП без написанных вручную костылей с указателями на функции, перегрузка операторов и функций.
Ну а disignated initializers будут в C++20. Наверняка в 2019-ом эта фича уже будет поддержана в компиляторах большой тройки (если не уже).
Когда в тот же раст завезут полноценную поддержку библиотек которыми я пользуюсь… тогда я попробую и оценю все преимущества.
Угу, когда появятся ваши библиотеки… когда перепишут ваши проекты… когда уговорят ваш менеджмент… когда ваши коллеги пересядут… когда все вокруг будут использовать в проде… Когда они пришли за мной — уже некому было заступиться за меня.
Я 2 года тихо пилил C++ легаси в Яндексе с мыслью, что я принадлежу илите. Как же, высокий грейд, хорошие оценки, премии. И надо мной ржали плюсоиды, когда я говорил, что через 3 года HR будут охотиться за растоманами, что будущее будет за Rust, ведь это технология, которая позволяет избавиться от целого класса проблем, присущих C++. И я психанул. Очень сильно.
Прошло 2 года моего опыта с Rust.
Я жестоко троллю mail.ru. Мои домашние проекты вызывают у людей ностальгию. Меня приглашают на конференцию в другую страну. Моему github аккаунту kpp выписывают благодарности в новости к ключевой технологий Rust — tokio. На конференциях ко мне подходят люди со словами: "О, ты тот самый kpp". О да, это я. И большинство из них работают на иностранные компании.
Да, раст еще зеленый, со своими тараканами, но, пожалуйста, не мешайте делать людям выбор в его пользу фразами типа: "Нельзя просто так взять и удержаться от упоминания раста в теме по С++".
Не мешайте им вливаться в дружелюбное сообщество, выходить на международный рынок, поднимать зп в N раз. <3
P.S. сам, подавляющее время, разработчик на C++ к Rust присматриваюсь, но в моих задачах он пока неприменим поскольку нет возможности добавить его поддержку.
Вы знаете, я писал на C++ почти 20 лет, из них 17 — коммерческая разработка. В том числе почти 10 лет немного похожий на геймдев проект. Писал как используя шаблонное метапрограммирование, так и ограниченный диалект C с классами. С range v3 упомянутым в статье кстати хорошо знаком и очень жалею, что это до сих пор не в стандарте. А года полтора назад познакомился с растом, пробовал писать на нём несколько мелких хобби проектов, и вот прям не покидает ощущение, что это "C++ done right". И видимо я далеко не один такой.
— Комитет С++ вообще никак не занимается вопросами оптимизации инструментов (и инструментами), как и вопросами «как нам сделать чтобы в дебаге код был быстрый».
Имхо, если кому-то это важно, пусть пинают вендора, чтобы запилил в библиотеке флаг, с которым в начале включается pragma optimize, а в конце — выключается.
Я лично частенько отлаживаю код в релизе, если мне нужна прям хорошая работа отладчика со всем стеком в конкретном файле, я добавляю сразу после инклюдов подавление оптимизации (работает для MSVC и clang по крайней мере).
В общем, как там релизную сборку отлаживать — это точно мимо. Мимо и комитета, и мимо претензий к языку
— следующее, про скорость сборки. Тут половина в целом по делу, как не оптимизируй, какие-то вещи тупо алгоритмически сложные. Но! Я заметил некоторую общую претензию и к реализации Ranges, и к Boost, мол это монструозно и т.п.
Boost — стремится быть в первую очередь портируемым. никакой цели оптимизировать скорость сборки там точно нет. Ну и для меня это скорее как такая площадка использовать заранее то, чего пока нет в стандарте:
1. Boost, медленно собирается, немножко багов
2. --smth-ts, experimental/ — собирается уже быстро, т.к. привязано к конкретной платформе, багов +- (скорее всего нет платформоспецифичных, но потенциально могут быть в другой логике)
3. std — и быстро, и с минимумом багов. (возможно в качестве бонуса еще с урезанным функционалом по сравнению с Boost, правда).
Я это очень грубо, понято, что наверное можно найти и контрпримеры. Но я к тому, что используя Boost ты сразу соглашаешься что сборка будет медленной.
Собственно, я полагаю, если вместо вот этой жести
github.com/ericniebler/range-v3/blob/master/include/meta/meta.hpp
будет специфичная для современного компилятора реализация на constexpr-ах, то все это будет сильно быстрее (constexpr everything тренд).
ну и вообще не понимаю оправданий «отладка STL тормозит» — «ну так надо, это цена которую ты платишь за абстракции» — КАТЕГОРИЧЕСКИ против такого подхода, идеология С++ — «не платишь за то, что не используешь». Собственно, если мне не надо отлаживать STL, я не должен за него платить.
Про тестирование хочу привести пару примеров-исключений, подтверждающих правило: Factorio automated tests и Mr. Bot из The Talos Principle. По этим примерам видно, насколько сложными должны быть тесты геймплея, и почему они действительно почти нигде не присутствуют.
Мысли о современном C++ и игровой разработке