О то же с mini-itx помучился, в принципе у меня был нормальный вариант, в корпусе Fractal Design node 304, но пришло время апгрейда и куча НО, много жестких дисков не вставишь, нет с корпусом все хорошо позволяет до 6 дисков ставить, но матери дорого, ограничено и плохо, плюс корпус не обеспечивает шумоизоляцию. В итоге переехал в Fractal Design Define R5, мать B550 чипсет, Ryzen 3600Х, 32GB оперативы, 3x4Гб жестких диска в рейде + 1Тб ssd под систему. В качестве ОС выбрал TrueNAS Scale, планирую еще добавить рейд на ssd под ускорение работы витуалок и возможно расширить память до 96Гб. Понимаю что это дорохо-бахато и не каждый на такое раскошелится, но мне как для личных нужд так и под хоумпроджекты, а самое главное достало постоянно возиться с настройкой системы под разные тесты задачи, на рабочем/домашнем компе их много не развернешь, да и он на ночь выключается, потом все это включать. А сейчас стало прям хорошо, тишина идеальная, сервер вообще не слышно, стоит в прихожей, около роутера, нужна виртуалка - поднимается за 5 минут чистая. И еще точно плюс в том что если начну в проц упираться могу до 16 ядер апнуть.
Пришел к выводу что сервер нужно строить вокруг корпуса, покупаешь максимально тяжелый, закрытый, тихий и хорошо вентилируемый.
"Прототипирование цифровых устройств" Разве малинка с гребенкой выводов не позволяет делать то же самое или речь о прототипирование очень маленькой микросхемы типа датчика который должен быть очень дешевым?
"Устройства с требованием реакции в реальном времени" Тут все понятно, действительно не подумал.
"Цислодробильня в реальном времени (нейронки, ЦОС) с приемлемым энергопотреблением" GPU разве не лучше будут?
"Секретность устройств(военщина)" Речь как понимаю опять же о прототипирование маленького микроконтроллера который к примеру кодирует и раскодирует речь в реальном времени.
"Устройства с возможностью последующих изменений хардварной логики" то есть FPGA может работать как алгоритм выполненный в кремнии, без различного рода задержек, фактически из него можно делать программируемый сигнальный процессор?
А какие? Просто действительно FPGA это тема которую обошел стороной, мне ничего в голову не приходит кроме как запечь в FPGA нейросетку и быстро распознавать пространство, предметы, но опять же, может на малине мощности GPU не хватит, но топовые спапдраконы и апл бионики на GPU нейронки с какой-то космической скоростью гоняют + там нейроблоки разные.
Пишу не с целью покритиковать и потролить, действительно интересно что с их помощью лучше делать.
Может чего не понимаю? Это же FPGA и он больше нужен для отладки логики аппаратных блоков, зачем на нем делать "полноценный мини-компьютер на Linux c выводом изображения в HDMI и подключением клавиатуры по USB" для мини-компьютеров есть малина, оранж и тысячи их. Честно сказать мало поружен в тему FPGA, не сильно понимаю зачем он нужен, при текущей цене и быстродействие различных контроллеров, разве не проще все просто запрограммировать?
А я все думаю почему мегановая оптика работает по вечерам как типичный wi-fi увеличиваются пинги и теряется скорость. Думал что это просто провайдер не справляется, а дело скорее всего в том что у меня в доме все включают по вечерам телек посмотреть и половина общего канала проваливается. Печально. Жалко что обычно по провайдерам вообще нет альтернативы в доме. Если кто-то из крупных уже зашел остальные стоят в стороне, годами.
Интересно наблюдать за комментаторами типа вас, сначала было "в россии все плохо и ничего российского никогда не будет", начали появляться новости о разработке, там сям, случилась эволюция "все равно это купить нельзя все это только для распила, вот когда будет в магазине поговорим", сейчас это есть в магазине и можно пойти и купить, и снова эволюция "да зачем оно надо, оно дороже и хуже". Вы дураком не прикидывайтесь, по-моему автор явно дал понять что он это покупает потому что верит в отечественное хай-тек железо, не важно насколько оно хуже мака на м1, оно спроектировано и сделано его коллегами, которых он знает лично. Ему не интересен труд каких-то там разработчиков на тайване или в кремниевой долине, ему интересно попробовать то что делают его соотечественники. И меня очень радует что есть такие люди, потому что они есть мое окружение. Часто замечаю что есть люди "перебежчики" они стремятся туда где уже хорошо, где кто-то уже построил хорошее окружение, а есть люди строители, им не интересно чужое им интересно свое, такие люди едут в глухую деревню и делают из нее успешное агропроизводство, на таких людях мир держится.
Все так, полностью согласен с каждым тезисом. У каждого инструмента есть свой критерий применимости. Электрона в моем мире не должно было бы существовать. Но если в принципе зарубить концепцию JIT, то перестанет работать и Qt/QML, а он то же использует JIT и это, на мой взгляд, лучшее что существует сейчас для создания UI приложений. Опять же java, там то же используется JIT, и изначально java проектировалась именно для маломощных систем. Дело не в том что концепция плохая, а в том что люди начинают использовать ее бездумно. Скрипты нужны не для написания основной массы кода, а как клей который склеивает бинарные строительные блоки. В таком случае будет и гибкость и скорость разработки и отсутствие проблем потребления ресурсов.
Зря вы так про JIT, в целом полностью с вами согласен во всех тезисах, и философско-политических в том числе. И очень радостно что есть люди с такой позицией. Но JIT удобная вещь, lua, js, без них очень сложно делать игры. Они все кривые, ужасные и полное г..но по сравнению с с++ или даже паскалем, но решают одну важную вещь, позволяют загрузить(скачать) и исполнить кусок кода. А это невероятно удобно для модов и различного рода ДЛЦ. В многих предметных областях есть задачи где не нужен код всей системы, но нужно отдать на откуп часть поведения людям на стороне. Понятно что интерпретатор не есть JIT, но как только начинается интерпретация сразу хочет JIT что бы оно хоть как-то по перфу работало.
Идея в том что бы брать что-то хорошее из одной системы и адаптировать для другой системы. Если не подходит чистый Дракон, можно сделать же какую-то подходящую модификацию на основе идеи дракона о том что одинаковые логически схемы выглядят одинаково. Как мне видится нодовый редактор квестов, это обычный нодовый редактор, только с автоматическим позиционированием элементов. Возможно это нельзя сделать в полной мере, возможно вообще нельзя, у меня еще не было возможности проработать эту идею.
Точно не легко, такую работу вижу каждый день, без минимальной цветовой раскраски невозможно работать, в экселе это решали заливкой ячеек. И мысль пока развивается в сторону примерно такого редактора, но никто не пробовал насколько удобно будет им пользоваться, это красиво выглядит когда в демке примерно 1% от необходимого контента, что будет когда добавят остальные 99% не понятно, но думаю что в любом случае будет лучше, если не давать пользователям свободно размещать блоки и связи, а контролировать геометрическое расположение блоков будут правила как в Драконе.
Попробуйте в коде задать граф квестов и потом научить гейм-дизайнеров его делать, некоторые структуры гораздо проще задавать визуально, графы это одна из них, дракон это грубо говоря правила упорядочивания графа, что бы он не превращался в огромного макаронного монстра.
Даже табличное представление квестового графа это полная ж... ГД тут же начинают плакать и просить цветовую подкраску что бы хоть как-то читать это.
Йо вэй, денег просят государственных, а технологии будут частными. Национализация расходов и приватизация прибылей. Так не годится. Если МЦСТ хочет денег государственных, то и результаты ее работы то же должны принадлежать государству, то есть быть открытыми. Это касается всех и тех кто хочет на RISC-V процессоры делать. Конечно же нужно поддерживать микроэлектронику. Но порождать монополию то же нельзя. У МЦСТ отличный план: сначала дайте денег, потом примите закон что бы покупать можно было только наше, потом перепишите весь софт, а дальше мы будем диктовать цены и продавать за столько за сколько захотим, когда займем нишу.
С компиляцией последнее время почти нет проблем, прекомпиленые хидеры это понятно, сейчас добавилась инкрементальная линковка. Плюс компилируется то что менялось, плюс появились очень многопоточные процессоры. Ну и мне даже иногда нравится задержка перед запуском программы, те 30-40 секунд что обычно работает компилятор хватает что бы подумать что будешь писать дальше. Еще в студии очень удобная фича компилировать только файл на котором курсор стоит.
"ноги простреливаются" проблема сильно преувеличена чем она есть на самом деле. Там вот выше чет про memcpy терли, даже вчитываться не стал, обычно такой код не пишется, обычно работа идет на несколько более высоком уровне, если есть данные они скорее всего хранятся в контейнере, а если нужно скопировать контейнер, std::copy, std::transform, да тонкие оптимизации так не сделаешь. Для тонких оптимизаций есть профилировщик и опять же в 90% случаев проблема будет в архитектуре или алгоритме. Но если у вас супер критичный код и прям вот надо выжать все, ну ок, почитай справку и сделай все аккуратно. Так то и до асма можно дойти при желании. С++ сильно мультипарадигменный. Опять же проблема современного программирования, приходится постоянно переключаться с разных языков, что-то на питоне сделать по автоматизации, что-то на нативе(objective c, java), пол игры вообще на lua написано, система сборки на cmake, держать в голове тонкости работы 5-6 языков не возможно, как минимум в моей, поэтому ок гугл, хау то... и поехали, все мы в той или иной мере фулстековерфлоу программисты.
BGL - кровь из глаз, кто же спорит, boost.spirit - ну нахер, апи curl - хочется пойти выйти в окно, но есть cpr. Подключить библиотеку - да сдохнуть можно было еще лет 10 назад, но появился cmake, а потом конан и vcpkg стало как-то очень полегче, но все равно, есть Tesseract, от которого много что зависит на тему распознавания, он начал под mac-arm64 собираться из коробки месяц назад, до этого приходилось патчить и до сих пор в vcpkg либ у которых в портфайлах !arm написано валом. Но понимаете в чем дело BGL то есть и он работает, и аналогов по спектру решения задач не особо много, скажем почти нет, а какая альтернатива в других языка? Сесть написать свои алгоритмы, а потом годами в них ловить ошибки на корнеркейсах?
Альтернатива это всегда хорошо, не было бы руби-на-рельсах, пипа, никто бы и не почесался в с++ на тему пакетного менеджера. Питон очень хорош для автоматизации и прототипов, даже если взять qt, я не буду больше никогда на виджетах ничего писать, скорее всего, потому что qml дает больше и лучше, а там с++ загнан под капот и вообще все на js. Альтернативы дают новые подходы которые заставляют развиваться мир с++ и самые успешные альтернативы дают тебе не замену с++, а дополнение с++. Они не вместо, а они вместе. Ни для кого не секрет что под капотом питона все так или иначе использует с++, у явы есть JNI.
Что пишу, в основном геймдев: движки, внутренние редакторы и различные утилиты. Геймплей, понятно, что это будет или скриптовый язык или квестовый граф, в общем то что можно быстро и легко переделывать, а вот различная работа с ресурсами, рендер, сеть и прочее это будет или натив или с++. Вот что-то такое и пишу, делаю все что бы гемплей командам жилось хорошо и беззаботно. В геймдеве работы много и она разная, можно менять специализацию при желании. Лично по-моему опыту уровень задач и их качество зависит от рук, а не от технологии, Языки, фреймворки все плюс минус одинаковое. Мне нравится связка C++/qt потому что более менее понимаю как этим пользоваться, плюс есть огромная поддержка с++ со стороны различных сторонних бибилиотек. Ну к примеру есть boost::graph мне не понятно что будут делать специалисты на флуттере если им нужно будет в графе найти остова, с помощью буста это решается щелчком пальца, а там что, сидеть самому писать алгоритмы? Или к примеру иногда приходится делать свой язык под задачу, берешь bison/flex и вперед можно antrl, а на флуттер что делать? Antrl может быть конечно уже и сделали биндинги в Дарт, не следил как-то. Но опять же мне Antrl парсеры меньше заходят, и bison уже умею пользоваться. Мне минимум два раза встречались задачи на использование шаблонизатора, первый раз лет 10 назад для генерации отчетов и печатных форм, второй раз вот совсем недавно что бы дать возможно аналитикам делать выборки по балансу для своих моделей, в обоих случая логично было бы прикрутить скриптовый язык, в одном случае пошел js в другом lua, плюс автоматизацию для тестировщиков писали в одном случае прикрутили биндинг в питон по парсенгу логов перфа с ночных билдов, во втором случае взяли ChaiScript и дали возможность писать тестовые сценарии для фермы мобильных клиентов, на скрипте описывались сценарии для всех устройств. Ну к примеру заходят в бой два клиента и дерутся по определенному сценарию, за бой снимаются логи по перфу и потреблению памяти, а так же насколько у нас баланс сходится. В случае отклонения от референсных значений - алерт. Короче задача скриптования встает очень часто, и для с++ есть куча готовых решений: питон, луа, chaiscript и т.д. Делаю игру мне нужен отладочный UI - беру imgui и вперед. В одном из проектов нужен был профилировщик, сели написали профилировщик, как на дарте вообще это сделать, сначала написать биндинги winapi в дарт потом писать профилировщик? А насколько это долго будет работать у нас 5 минут игры генерили примерно 10 Гб логов(не текстовых, а ETL).
Вот автор статьи говорит про вебсокеты, и зачем после их появления нужен tcp, ну сделайте на вебсокетах пробой NAT через STUN/TURN. Это нужно например что бы экономить сотни тысяч долларов на раздаче DLC для игры. WoT обновления через торрент протокол раздает.
Я про всякое разное убийцы с++ слышу... сколько работаю столько и слышу, сначала был .NET все c# сейчас все убьет, UI только на нем, WinForms лучшее, очень быстро, очень качественно, программирую на с++, потом Flash, все кроссплатформенно, очень низкий порог входа все игры будет писать на нем и программы то же, веб все захватит, программирую на с++, потом электрон, очень круто, очень много разработчиков, очень быстро, все UI только на нем, продолжаю программировать на с++, сейчас вот флуттер, все с++ хана все только на нем, ну... как бы мое отношение понятно ) Нет какую-то нишу себе флуттер займет, как заняли и все убийцы с++ до этого, но с++ никуда не денется еще очень очень очень долго.
Своей команде позволяю писать как хотят, мне все равно, могу читать почти любой код в любом стиле, друг друга пока понимаем, код ревью вести не сложно. Но люди особо и не пишут ничего сложного, никто не рвется писать трехэтажные шаблоны. Сам стараюсь писать максимально просто, остальным то же рекомендую. Когда долго программируешь все равно приходится лезть в чужие библиотеки и так или иначе в них разбираться, со временем становится все равно на код стайл и гайдлайны. Скажу крамольную вещь, у нас сейчас команда 10+ программистов и даже кодстиля нет ), когда приходят новички по началу спрашивают про код стиль, говорю пишите примерно как в коде написано, ну и как-то нормально. На мой взгляд самый лучший способ разработки это не мешать бюрократией и проектировать постфактум, перед реализаций быстро прикинул что как, обсудил минут за 10, потом когда уже функциональность написана и ее много, вот тогда делать проектирование и рефакторить. То есть условно процесс разработки можно построить на два этапа, первый это говнякать прототип, который может и в релиз уйти, а потом уже систематизировать написанный код, уже зная как он работает и какую задачу решает, систематизировать. Причем эти два процесса должны идти все время, так лично по моему опыту получается лучше и быстрее разрабатывать даже достаточно крупные штуки. Беда начинается когда менеджеры вмешиваются и не дают проводить систематизацию: "ну оно же не привезет новых функций зачем работу делать". Более того слишком большое проектирование вначале как правило заканчивается овериндженерингом, а самое неприятное что в процессе реализации как правило приходит понимание что не учли, но так ТЛД уже написано начинают костылить и получается по качеству примерно то же самое что просто наговнякать, все равно набор подпорок и костылей. Так давайте говнякать сразу а потом уже сделаем начисто.
Это все звучит очень спорно и вразрез с общепринятыми подходами, возможно оно работает только у меня и еще у пары коллег, а у других такой подход работать не будет.
Мы используем из нового просто и понятное: optional, atomic, thread, filesystem, лямды, с новым стандартом появились хорошие библиотеки, например magic_enum. Вроде Rust развивается активно. С++ хорош тем что вокруг него есть миллиард библиотек и он работает почти везде.
Работаю уже лет 20(с первого курса) и подхожу к заветной точке 40+, так вот первым моим языком был С++, первым большим фреймворком был Qt, не поверите, но все что изучал еще в школе до сих пор вполне актуально. А самое главное без этого не строится ни один большой проект, автор работает в очень специфичной сфере, судя по примерам, веб-сайты, интернет магазины, мобильные приложения на Flutter, это очень маленькие проекты, это даже не программы в полном смысле, аналоги сайтов визиток популярных в начале 2000. Напишите пожалуйста хотя бы мессенджер без с++ или натива. Только нет вот это я тут взял фреймворк где за меня разрабочики фреймворка прикрутили webrtc сделали обертки в js и меня вот звонок уже идет. Нет, сделайте хотя бы звуковой кодек без си/с++. Про всякую пену типа флеш, электрона, теперь флуттер, слышу уже много лет, сколько работаю столько и слышу. Ну и как программировал UI на Qt, так и программирую. Конечно все эти модные штуки возьмут себе какое-то место под солнцем, хотя флеш вроде сдулся совсем, но с++ никуда не денется очень, очень много времени. А самое приятное что можно вообще не тратить время на новое разрабатывая на с++, ну к примеру появился std::thread, но что системные потоки перестали работать? появилось время можно посмотреть новый стандарт, не появилось пиши как раньше, работать не перестанет. И по перфу готов на с++/qt соревноваться с любой модной штукой. И самое что интересное, уверен в том что на с++ и qt будет реализована любая сколь угодно сложная задача в полном объеме и не упрусь в технологию, в крайнем случае пойду дергать нативное апи системы, будь то андроид, winapi или ios.
"теперь у нас в компании нет разработчиков мобильных приложений на нативных языках" это означает что вы можете решать класс задач только тот который дает флуттер и не больше, обсер произойдет сразу как понадобиться работать с камерой и выжимать перф для нейросетей.
Благо мы живем не в 2010, а в 2022, когда уже есть CMake, кросскомпиляция, компиляторы которые умеют генерировать код под любую платформу, куча открытого софта и библиотек, если в 2010 годы было вообще непонятно как обеспечить поддержку проекта в хкоде и вижуалстудии, то сейчас это делает щелчком пальца, ну почти. Сложность разработки кроссплатформенных программ понизилась в разы, если не на порядки. Даже для внутренних программ поддержка мака и виндовс считается чем-то самой собой разумеющимся. Так что если будут две конкурирующих платформы станет только лучше. Добавить RISC-V, MIPS и прочее станет значительно проще, чем при переходе от одного монополиста. Сейчас даже поддержка линукса, с его мемными 1,5% процентами пользователей, становится чем-то само собой разумеющимся, не у всех и не всегда, но тем не менее. Даже микрософт уже пилит софт для линукса. Я считаю, и с этим можно спорить, что устойчивость в многообразии.
О то же с mini-itx помучился, в принципе у меня был нормальный вариант, в корпусе Fractal Design node 304, но пришло время апгрейда и куча НО, много жестких дисков не вставишь, нет с корпусом все хорошо позволяет до 6 дисков ставить, но матери дорого, ограничено и плохо, плюс корпус не обеспечивает шумоизоляцию. В итоге переехал в Fractal Design Define R5, мать B550 чипсет, Ryzen 3600Х, 32GB оперативы, 3x4Гб жестких диска в рейде + 1Тб ssd под систему. В качестве ОС выбрал TrueNAS Scale, планирую еще добавить рейд на ssd под ускорение работы витуалок и возможно расширить память до 96Гб. Понимаю что это дорохо-бахато и не каждый на такое раскошелится, но мне как для личных нужд так и под хоумпроджекты, а самое главное достало постоянно возиться с настройкой системы под разные тесты задачи, на рабочем/домашнем компе их много не развернешь, да и он на ночь выключается, потом все это включать. А сейчас стало прям хорошо, тишина идеальная, сервер вообще не слышно, стоит в прихожей, около роутера, нужна виртуалка - поднимается за 5 минут чистая. И еще точно плюс в том что если начну в проц упираться могу до 16 ядер апнуть.
Пришел к выводу что сервер нужно строить вокруг корпуса, покупаешь максимально тяжелый, закрытый, тихий и хорошо вентилируемый.
"Прототипирование цифровых устройств" Разве малинка с гребенкой выводов не позволяет делать то же самое или речь о прототипирование очень маленькой микросхемы типа датчика который должен быть очень дешевым?
"Устройства с требованием реакции в реальном времени" Тут все понятно, действительно не подумал.
"Цислодробильня в реальном времени (нейронки, ЦОС) с приемлемым энергопотреблением" GPU разве не лучше будут?
"Секретность устройств(военщина)" Речь как понимаю опять же о прототипирование маленького микроконтроллера который к примеру кодирует и раскодирует речь в реальном времени.
"Устройства с возможностью последующих изменений хардварной логики" то есть FPGA может работать как алгоритм выполненный в кремнии, без различного рода задержек, фактически из него можно делать программируемый сигнальный процессор?
Стало чуть понятнее, спасибо!
А какие? Просто действительно FPGA это тема которую обошел стороной, мне ничего в голову не приходит кроме как запечь в FPGA нейросетку и быстро распознавать пространство, предметы, но опять же, может на малине мощности GPU не хватит, но топовые спапдраконы и апл бионики на GPU нейронки с какой-то космической скоростью гоняют + там нейроблоки разные.
Пишу не с целью покритиковать и потролить, действительно интересно что с их помощью лучше делать.
Может чего не понимаю? Это же FPGA и он больше нужен для отладки логики аппаратных блоков, зачем на нем делать "полноценный мини-компьютер на Linux c выводом изображения в HDMI и подключением клавиатуры по USB" для мини-компьютеров есть малина, оранж и тысячи их. Честно сказать мало поружен в тему FPGA, не сильно понимаю зачем он нужен, при текущей цене и быстродействие различных контроллеров, разве не проще все просто запрограммировать?
А я все думаю почему мегановая оптика работает по вечерам как типичный wi-fi увеличиваются пинги и теряется скорость. Думал что это просто провайдер не справляется, а дело скорее всего в том что у меня в доме все включают по вечерам телек посмотреть и половина общего канала проваливается. Печально. Жалко что обычно по провайдерам вообще нет альтернативы в доме. Если кто-то из крупных уже зашел остальные стоят в стороне, годами.
Интересно наблюдать за комментаторами типа вас, сначала было "в россии все плохо и ничего российского никогда не будет", начали появляться новости о разработке, там сям, случилась эволюция "все равно это купить нельзя все это только для распила, вот когда будет в магазине поговорим", сейчас это есть в магазине и можно пойти и купить, и снова эволюция "да зачем оно надо, оно дороже и хуже". Вы дураком не прикидывайтесь, по-моему автор явно дал понять что он это покупает потому что верит в отечественное хай-тек железо, не важно насколько оно хуже мака на м1, оно спроектировано и сделано его коллегами, которых он знает лично. Ему не интересен труд каких-то там разработчиков на тайване или в кремниевой долине, ему интересно попробовать то что делают его соотечественники. И меня очень радует что есть такие люди, потому что они есть мое окружение. Часто замечаю что есть люди "перебежчики" они стремятся туда где уже хорошо, где кто-то уже построил хорошее окружение, а есть люди строители, им не интересно чужое им интересно свое, такие люди едут в глухую деревню и делают из нее успешное агропроизводство, на таких людях мир держится.
Все так, полностью согласен с каждым тезисом. У каждого инструмента есть свой критерий применимости. Электрона в моем мире не должно было бы существовать. Но если в принципе зарубить концепцию JIT, то перестанет работать и Qt/QML, а он то же использует JIT и это, на мой взгляд, лучшее что существует сейчас для создания UI приложений. Опять же java, там то же используется JIT, и изначально java проектировалась именно для маломощных систем. Дело не в том что концепция плохая, а в том что люди начинают использовать ее бездумно. Скрипты нужны не для написания основной массы кода, а как клей который склеивает бинарные строительные блоки. В таком случае будет и гибкость и скорость разработки и отсутствие проблем потребления ресурсов.
Зря вы так про JIT, в целом полностью с вами согласен во всех тезисах, и философско-политических в том числе. И очень радостно что есть люди с такой позицией. Но JIT удобная вещь, lua, js, без них очень сложно делать игры. Они все кривые, ужасные и полное г..но по сравнению с с++ или даже паскалем, но решают одну важную вещь, позволяют загрузить(скачать) и исполнить кусок кода. А это невероятно удобно для модов и различного рода ДЛЦ. В многих предметных областях есть задачи где не нужен код всей системы, но нужно отдать на откуп часть поведения людям на стороне. Понятно что интерпретатор не есть JIT, но как только начинается интерпретация сразу хочет JIT что бы оно хоть как-то по перфу работало.
Идея в том что бы брать что-то хорошее из одной системы и адаптировать для другой системы. Если не подходит чистый Дракон, можно сделать же какую-то подходящую модификацию на основе идеи дракона о том что одинаковые логически схемы выглядят одинаково. Как мне видится нодовый редактор квестов, это обычный нодовый редактор, только с автоматическим позиционированием элементов. Возможно это нельзя сделать в полной мере, возможно вообще нельзя, у меня еще не было возможности проработать эту идею.
Точно не легко, такую работу вижу каждый день, без минимальной цветовой раскраски невозможно работать, в экселе это решали заливкой ячеек. И мысль пока развивается в сторону примерно такого редактора, но никто не пробовал насколько удобно будет им пользоваться, это красиво выглядит когда в демке примерно 1% от необходимого контента, что будет когда добавят остальные 99% не понятно, но думаю что в любом случае будет лучше, если не давать пользователям свободно размещать блоки и связи, а контролировать геометрическое расположение блоков будут правила как в Драконе.
Попробуйте в коде задать граф квестов и потом научить гейм-дизайнеров его делать, некоторые структуры гораздо проще задавать визуально, графы это одна из них, дракон это грубо говоря правила упорядочивания графа, что бы он не превращался в огромного макаронного монстра.
Даже табличное представление квестового графа это полная ж... ГД тут же начинают плакать и просить цветовую подкраску что бы хоть как-то читать это.
Йо вэй, денег просят государственных, а технологии будут частными. Национализация расходов и приватизация прибылей. Так не годится. Если МЦСТ хочет денег государственных, то и результаты ее работы то же должны принадлежать государству, то есть быть открытыми. Это касается всех и тех кто хочет на RISC-V процессоры делать. Конечно же нужно поддерживать микроэлектронику. Но порождать монополию то же нельзя. У МЦСТ отличный план: сначала дайте денег, потом примите закон что бы покупать можно было только наше, потом перепишите весь софт, а дальше мы будем диктовать цены и продавать за столько за сколько захотим, когда займем нишу.
С компиляцией последнее время почти нет проблем, прекомпиленые хидеры это понятно, сейчас добавилась инкрементальная линковка. Плюс компилируется то что менялось, плюс появились очень многопоточные процессоры. Ну и мне даже иногда нравится задержка перед запуском программы, те 30-40 секунд что обычно работает компилятор хватает что бы подумать что будешь писать дальше. Еще в студии очень удобная фича компилировать только файл на котором курсор стоит.
"ноги простреливаются" проблема сильно преувеличена чем она есть на самом деле. Там вот выше чет про memcpy терли, даже вчитываться не стал, обычно такой код не пишется, обычно работа идет на несколько более высоком уровне, если есть данные они скорее всего хранятся в контейнере, а если нужно скопировать контейнер, std::copy, std::transform, да тонкие оптимизации так не сделаешь. Для тонких оптимизаций есть профилировщик и опять же в 90% случаев проблема будет в архитектуре или алгоритме. Но если у вас супер критичный код и прям вот надо выжать все, ну ок, почитай справку и сделай все аккуратно. Так то и до асма можно дойти при желании. С++ сильно мультипарадигменный. Опять же проблема современного программирования, приходится постоянно переключаться с разных языков, что-то на питоне сделать по автоматизации, что-то на нативе(objective c, java), пол игры вообще на lua написано, система сборки на cmake, держать в голове тонкости работы 5-6 языков не возможно, как минимум в моей, поэтому ок гугл, хау то... и поехали, все мы в той или иной мере фулстековерфлоу программисты.
BGL - кровь из глаз, кто же спорит, boost.spirit - ну нахер, апи curl - хочется пойти выйти в окно, но есть cpr. Подключить библиотеку - да сдохнуть можно было еще лет 10 назад, но появился cmake, а потом конан и vcpkg стало как-то очень полегче, но все равно, есть Tesseract, от которого много что зависит на тему распознавания, он начал под mac-arm64 собираться из коробки месяц назад, до этого приходилось патчить и до сих пор в vcpkg либ у которых в портфайлах !arm написано валом. Но понимаете в чем дело BGL то есть и он работает, и аналогов по спектру решения задач не особо много, скажем почти нет, а какая альтернатива в других языка? Сесть написать свои алгоритмы, а потом годами в них ловить ошибки на корнеркейсах?
Альтернатива это всегда хорошо, не было бы руби-на-рельсах, пипа, никто бы и не почесался в с++ на тему пакетного менеджера. Питон очень хорош для автоматизации и прототипов, даже если взять qt, я не буду больше никогда на виджетах ничего писать, скорее всего, потому что qml дает больше и лучше, а там с++ загнан под капот и вообще все на js. Альтернативы дают новые подходы которые заставляют развиваться мир с++ и самые успешные альтернативы дают тебе не замену с++, а дополнение с++. Они не вместо, а они вместе. Ни для кого не секрет что под капотом питона все так или иначе использует с++, у явы есть JNI.
Что пишу, в основном геймдев: движки, внутренние редакторы и различные утилиты. Геймплей, понятно, что это будет или скриптовый язык или квестовый граф, в общем то что можно быстро и легко переделывать, а вот различная работа с ресурсами, рендер, сеть и прочее это будет или натив или с++. Вот что-то такое и пишу, делаю все что бы гемплей командам жилось хорошо и беззаботно. В геймдеве работы много и она разная, можно менять специализацию при желании. Лично по-моему опыту уровень задач и их качество зависит от рук, а не от технологии, Языки, фреймворки все плюс минус одинаковое. Мне нравится связка C++/qt потому что более менее понимаю как этим пользоваться, плюс есть огромная поддержка с++ со стороны различных сторонних бибилиотек. Ну к примеру есть boost::graph мне не понятно что будут делать специалисты на флуттере если им нужно будет в графе найти остова, с помощью буста это решается щелчком пальца, а там что, сидеть самому писать алгоритмы? Или к примеру иногда приходится делать свой язык под задачу, берешь bison/flex и вперед можно antrl, а на флуттер что делать? Antrl может быть конечно уже и сделали биндинги в Дарт, не следил как-то. Но опять же мне Antrl парсеры меньше заходят, и bison уже умею пользоваться. Мне минимум два раза встречались задачи на использование шаблонизатора, первый раз лет 10 назад для генерации отчетов и печатных форм, второй раз вот совсем недавно что бы дать возможно аналитикам делать выборки по балансу для своих моделей, в обоих случая логично было бы прикрутить скриптовый язык, в одном случае пошел js в другом lua, плюс автоматизацию для тестировщиков писали в одном случае прикрутили биндинг в питон по парсенгу логов перфа с ночных билдов, во втором случае взяли ChaiScript и дали возможность писать тестовые сценарии для фермы мобильных клиентов, на скрипте описывались сценарии для всех устройств. Ну к примеру заходят в бой два клиента и дерутся по определенному сценарию, за бой снимаются логи по перфу и потреблению памяти, а так же насколько у нас баланс сходится. В случае отклонения от референсных значений - алерт. Короче задача скриптования встает очень часто, и для с++ есть куча готовых решений: питон, луа, chaiscript и т.д. Делаю игру мне нужен отладочный UI - беру imgui и вперед. В одном из проектов нужен был профилировщик, сели написали профилировщик, как на дарте вообще это сделать, сначала написать биндинги winapi в дарт потом писать профилировщик? А насколько это долго будет работать у нас 5 минут игры генерили примерно 10 Гб логов(не текстовых, а ETL).
Вот автор статьи говорит про вебсокеты, и зачем после их появления нужен tcp, ну сделайте на вебсокетах пробой NAT через STUN/TURN. Это нужно например что бы экономить сотни тысяч долларов на раздаче DLC для игры. WoT обновления через торрент протокол раздает.
Я про всякое разное убийцы с++ слышу... сколько работаю столько и слышу, сначала был .NET все c# сейчас все убьет, UI только на нем, WinForms лучшее, очень быстро, очень качественно, программирую на с++, потом Flash, все кроссплатформенно, очень низкий порог входа все игры будет писать на нем и программы то же, веб все захватит, программирую на с++, потом электрон, очень круто, очень много разработчиков, очень быстро, все UI только на нем, продолжаю программировать на с++, сейчас вот флуттер, все с++ хана все только на нем, ну... как бы мое отношение понятно ) Нет какую-то нишу себе флуттер займет, как заняли и все убийцы с++ до этого, но с++ никуда не денется еще очень очень очень долго.
" Если бы мне предложили реализовывать его на базе С++, я бы такое запретил. "
Это очень хорошо. Фактически чем больше будет людей разделяющих ваши взгляды тем выше будет моя зп.
Своей команде позволяю писать как хотят, мне все равно, могу читать почти любой код в любом стиле, друг друга пока понимаем, код ревью вести не сложно. Но люди особо и не пишут ничего сложного, никто не рвется писать трехэтажные шаблоны. Сам стараюсь писать максимально просто, остальным то же рекомендую. Когда долго программируешь все равно приходится лезть в чужие библиотеки и так или иначе в них разбираться, со временем становится все равно на код стайл и гайдлайны. Скажу крамольную вещь, у нас сейчас команда 10+ программистов и даже кодстиля нет ), когда приходят новички по началу спрашивают про код стиль, говорю пишите примерно как в коде написано, ну и как-то нормально. На мой взгляд самый лучший способ разработки это не мешать бюрократией и проектировать постфактум, перед реализаций быстро прикинул что как, обсудил минут за 10, потом когда уже функциональность написана и ее много, вот тогда делать проектирование и рефакторить. То есть условно процесс разработки можно построить на два этапа, первый это говнякать прототип, который может и в релиз уйти, а потом уже систематизировать написанный код, уже зная как он работает и какую задачу решает, систематизировать. Причем эти два процесса должны идти все время, так лично по моему опыту получается лучше и быстрее разрабатывать даже достаточно крупные штуки. Беда начинается когда менеджеры вмешиваются и не дают проводить систематизацию: "ну оно же не привезет новых функций зачем работу делать". Более того слишком большое проектирование вначале как правило заканчивается овериндженерингом, а самое неприятное что в процессе реализации как правило приходит понимание что не учли, но так ТЛД уже написано начинают костылить и получается по качеству примерно то же самое что просто наговнякать, все равно набор подпорок и костылей. Так давайте говнякать сразу а потом уже сделаем начисто.
Это все звучит очень спорно и вразрез с общепринятыми подходами, возможно оно работает только у меня и еще у пары коллег, а у других такой подход работать не будет.
Мы используем из нового просто и понятное: optional, atomic, thread, filesystem, лямды, с новым стандартом появились хорошие библиотеки, например magic_enum. Вроде Rust развивается активно. С++ хорош тем что вокруг него есть миллиард библиотек и он работает почти везде.
Работаю уже лет 20(с первого курса) и подхожу к заветной точке 40+, так вот первым моим языком был С++, первым большим фреймворком был Qt, не поверите, но все что изучал еще в школе до сих пор вполне актуально. А самое главное без этого не строится ни один большой проект, автор работает в очень специфичной сфере, судя по примерам, веб-сайты, интернет магазины, мобильные приложения на Flutter, это очень маленькие проекты, это даже не программы в полном смысле, аналоги сайтов визиток популярных в начале 2000. Напишите пожалуйста хотя бы мессенджер без с++ или натива. Только нет вот это я тут взял фреймворк где за меня разрабочики фреймворка прикрутили webrtc сделали обертки в js и меня вот звонок уже идет. Нет, сделайте хотя бы звуковой кодек без си/с++. Про всякую пену типа флеш, электрона, теперь флуттер, слышу уже много лет, сколько работаю столько и слышу. Ну и как программировал UI на Qt, так и программирую. Конечно все эти модные штуки возьмут себе какое-то место под солнцем, хотя флеш вроде сдулся совсем, но с++ никуда не денется очень, очень много времени. А самое приятное что можно вообще не тратить время на новое разрабатывая на с++, ну к примеру появился std::thread, но что системные потоки перестали работать? появилось время можно посмотреть новый стандарт, не появилось пиши как раньше, работать не перестанет. И по перфу готов на с++/qt соревноваться с любой модной штукой. И самое что интересное, уверен в том что на с++ и qt будет реализована любая сколь угодно сложная задача в полном объеме и не упрусь в технологию, в крайнем случае пойду дергать нативное апи системы, будь то андроид, winapi или ios.
"теперь у нас в компании нет разработчиков мобильных приложений на нативных языках" это означает что вы можете решать класс задач только тот который дает флуттер и не больше, обсер произойдет сразу как понадобиться работать с камерой и выжимать перф для нейросетей.
Все так, только вот сложность этого занятия была значительно выше. Собрать что-то написанное с использованием autoconfig тот еще квест.
Благо мы живем не в 2010, а в 2022, когда уже есть CMake, кросскомпиляция, компиляторы которые умеют генерировать код под любую платформу, куча открытого софта и библиотек, если в 2010 годы было вообще непонятно как обеспечить поддержку проекта в хкоде и вижуалстудии, то сейчас это делает щелчком пальца, ну почти. Сложность разработки кроссплатформенных программ понизилась в разы, если не на порядки. Даже для внутренних программ поддержка мака и виндовс считается чем-то самой собой разумеющимся. Так что если будут две конкурирующих платформы станет только лучше. Добавить RISC-V, MIPS и прочее станет значительно проще, чем при переходе от одного монополиста. Сейчас даже поддержка линукса, с его мемными 1,5% процентами пользователей, становится чем-то само собой разумеющимся, не у всех и не всегда, но тем не менее. Даже микрософт уже пилит софт для линукса. Я считаю, и с этим можно спорить, что устойчивость в многообразии.