#с — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #с, aggregated by home.social.
-
Хороший код, минусов нет: встреча «плюсовиков» YADRO и C++ Russia
У ДДТ был свой ответ на вопрос «что такое осень». И даже не один. У C++-разработчиков — свой: это когда вместо листьев разлетаются корутины, вместо дождя — потоки событий, а select и poll внезапно становятся отличной темой для вечерней встречи. 10 сентября в 18:30 проверим эту версию на мероприятии YADRO и C++ Russia. В программе — два технических доклада от разработчиков «Лаборатории Касперского» и YADRO. Перед выступлениями Александр Иргер, эксперт по разработке ПО в области телекоммуникаций, расскажет о планах московского сообщества «плюсовиков» и о том, над какими задачами работают сотни разработчиков на С++ в YADRO. Чтобы присоединиться к встрече в любом формате, пожалуйста,
-
Оптимизируем код решения СЛАУ методом Гаусса под процессор Эльбрус‑8СВ
Здравствуйте, друзья, меня зовут Ерохин Кирилл, я программист-любитель, а по совместительству популяризатор российского программного и аппаратного обеспечения, и в этом сентябре я провожу второе (теперь ежегодное) соревнование по алгоритмическому программированию на C/C++ для платформы Эльбрус (e2k), для студентов и выпускников со всей России «Кубок СЭРПАС 2026». Сегодня мне нужно дать участникам соревнования пример оптимизации кода под процессор Эльбрус-8СВ, а Хабр мне в этом поможет, ему не впервой.
https://habr.com/ru/articles/1071148/
#спортивное_программирование #олимпиадное_программирование #с++ #соревнования_по_программированию #эльбрус8св #e2k #эльбрус #сообщество #энтузиасты #оптимизация_кода
-
Как мы связали хаптик с промышленным роботом и учим его повторять движения полировщика
Привет, я Иван из НИИ Крокодил. Это небольшая команда внутри ИЖ‑РЭСТ — завода штампов и пресс‑форм. Мы пришли на завод из IT и теперь разбираемся, как соединить опыт людей из цеха с тем, что умеем сами. Недавно у нас появилась идея автоматизировать часть процесса полировки. В теории всё выглядело довольно просто: взять хаптик, связать его с промышленным роботом и научить сотрудников завода с этим работать. Для проверки гипотезы мы обратились к специалистам Университета Иннополис. Они предоставили оборудование и помогли нам разобраться с платформой, а наша команда написала программный мост на C++ и начала проверять, сможет ли робот повторять движения человека. Двигаться вслед за хаптиком робот научился довольно быстро. С реальной полировкой всё оказалось сложнее. Но давайте по порядку.
-
C++-техрадар: что разработчики действительно готовы брать в работу
В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript. Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье. Посмотреть радар и принять участие в голосовании можно на странице проекта .
https://habr.com/ru/companies/kaspersky/articles/1067982/
#с++ #postgresql #cmake #bazel #git #tech_radar #bash #gdb #vs_code #clang
-
Как пишут базы данных на C#: RavenDb
Эта база данных покоряет своей продуманностью: индексы рождаются автоматически, система обновляется без вашего участия, а защита данных стоит на страже, словно крепость. И это лишь начало её возможностей. Ознакомиться
https://habr.com/ru/articles/1067642/
#RavenDb #База_Данных #Документноориентированная #многомодельная #С# #NET #ASPNET #Oren_Eini #Создание_Базы_Данных #СУБД
-
Продакшен пал, Милорд
Кривенгард был заложен в лето 23-е от начала правления короля Страструппа на скальном мысу у излучины Малой Невки, где река делает поворот и всякий, кто идёт с севера, вынужден либо переправляться под стенами, либо огибать болото и терять четыре дня. Первый его хозяин, поставил на мысу одну башню и деревянный частокол, чего хватало, покудова не пришли те, кому этого не хватило. С той поры замок перестраивали одиннадцать раз, и каждая перестройка была ответом на осаду, которая уже случилась, а не на ту, которая случится. Оттого стены Кривенгарда не имели ни правильности, ни соразмерности и планов стройки, а северная куртина была толще южной вдвое, потому что в лето 27-е с севера подошли с тараном. Южная же осталась тонкой, ибо оттуда не подходил никто, и всякий раз, когда заходила речь о том, чтобы её усилить, находились дела важнее, срочнее и вчерашнее. Ворота были устроены так, что туда проходила только телега брата Ансельма, а всякий приезжий возчик ругался, что приходится перегружать товары, но всякий житель замка объяснял приезжему, что так сделал сам брат Ансельм, который жил в крепости со дня её основания. Спрашивать, впрочем, никто не ходил, ибо спрашивать было неловко, а брат Ансельм еще и отвечал так, что переспрашивать становилось ещё неловчее, ибо чувствовать себя дураком никто не любит. В северной стене, между третьим и четвёртым зубцом, был оставлен зазор шириной в ладонь и ни один из ныне живущих не знал его назначения. Знали только, что в 25-м году каменщик Юбер по собственному разумению заложил его известью, а через день в трапезной обрушился потолок, после чего зазор восстановили и более к нему не прикасались. К году, о котором пойдёт речь, гарнизон Кривенгарда насчитывал сто двадцать человек, из них пол сотни настоящих ратников, восемь десятников, и пять старейшин, а прочие кузнецы, конюхи, повара, водоносы, королевский астролог, двое алхимиков и семеро писцов. Еще появилось восемь башен, три двора, два колодца, четыре кузни, голубятня и писцовая палата, в которой по описи, тысяча девятьсот сорок шесть свитков с описанием разных вещей и комнат крепости, но недавно читаных из них было около двухсот.
https://habr.com/ru/articles/1064964/
#с++ #программирование #разработка_игр #игры_и_игровые_консоли
-
Если ссылки схлопываются, значит это кому‑то нужно
В прошлой статье ( Непослушный using ) я разобрал, как using вмешивается в поиск имён и почему его поведение часто расходится с тем, что от него ждет программист, и на этом ветку статей про поиск имен (name lookup) можно временно закрыть. Using'и попортят вам в проектах еще немало крови, но в целом их проблемы известны и легко ловятся, а теперь давайте поговорим об auto и выводе типов в шаблонах, который регулярно удивляет даже опытных программистов на C++, когда речь идёт о распаде типов (type decay) и неявных ловушках при работе с ним. Представьте, что у нас есть несколько переменных, которые выглядят разными: const int& , просто int , const int и int&& . По наивной интуиции можно подумать, что компилятор должен относиться к ним по‑разному: и где‑то ссылка, где‑то константность, где‑то rvalue, но это будет работать только до тех пор, пока мы не используем auto или шаблон. Потихоньку дописываю книгу, в целом каркас уже сложился и большая часть материала уже собрана и обработана в черновике, если вам интересно, что получилось, то главы выложены на гитхабе в русском и английском вариантах или тут, если вам больше нравится в виде статей , а то, что ещё дописывается уже больше шлифовка, чем поиск нужной формы. Оглавление и ссылки будут под катом.
https://habr.com/ru/articles/1064016/
#с++ #программирование #игры_и_игровые_консоли #разработка_игр
-
Как мы сделали протобаф-адаптер CONTRACT быстрее libprotobuf
CONTRACT умеет писать protobuf-совместимый wire-формат — и в 20 из 28 замеров обогнал по скорости настоящий libprotobuf, включая его собственный сгенерированный protoc-код. Разбираем три инженерных решения, которые это дали, и два сценария, где не получилось. CONTRACT — это C++ библиотека сериализации без кодогена и рантайм-рефлексии: схема объявляется один раз, в самой C+±структуре, и работает сразу под разные форматы.
-
Английский вместо кода
Язык, который придумали, чтобы программисты стали не нужны, породил профессию, которая жива до сих пор и неплохо оплачивается, а другой язык назвали "структурированным английским", и думали, что на нем сможет писать любой бухгалтер, и он тоже породил новую специальность со своей зарплатной вилкой. А еще была попытка сделать "программирование без программистов к двухтысячному году", но и он дал обратный результат. Думаю вы узнали COBOL, который по сей день ежедневно эксплуатируется и по разным оценкам стоит за 80% обычных (магазинных) банковских транзакций, а его кодовая база тянет на пару сотен миллиардов строк и до сих пор кормит десятки, если не сотни тысяч разработчиков. Правда, если копнуть эти красивые цифры, почти все они восходят к одному опросу конца девяностых, который потом бесконечно переэкстраполировали на весь мир, так что честнее считать их порядком величины, а не точными данными. SQL породил особую касту DBA (Database Administrators) и Data Engineers и сегодня человек, который пишет "простые запросы", может легко зарабатывать на уровне мидла, а сам язык стал настолько сложным, что современные диалекты (PostgreSQL, Oracle) - это полноценные языки программирования с процедурной логикой, где можно написать всё что угодно, от генератора фракталов до игрового движка. Семейство 4GL оказалось "золотой клеткой" и прекрасно работали, пока нужно было сделать типичную форму "ввод-вывод", но как только требовалась нестандартная бизнес-логика или интеграция с внешним сервисом, инструмент упирался в свои границы и программистам приходилось дописывать "костыли" на низкоуровневых языках, что превращало разработку в адский коктейль из визуального дизайна и грязных хаков. И вместо исчезновения программистов, 4GL создали "архитекторов корпоративных систем", которые (например, SAP ABAP), стали невероятно дорогими специалистами, и тоже не устранил программирование, а просто переместил его из зоны "универсальных языков" в зону "дорогих и капризных инструментов", привязывающих компанию к конкретному вендору. Каждые десять-пятнадцать лет индустрия торжественно объявляет, что писать код руками больше не придётся, продавая новый способ "объяснить машине задачу на нормальном человеческом языке". И каждый раз через несколько лет выясняется, что программистов стало не меньше, а больше, просто теперь они называются иначе. Предположу, что сейчас мы проживаем очередной виток этого цикла, и новое название таким людям будет вайбкодеры, и думаю этому инструменту, уготована та же судьба, что и у предыдущих попыток.
-
Практика программирования в эпоху ИИ (разбор реальной задачи на С++ с помощью ИИ агента)
Мне кажется когда мы начинаем обсуждать с ИИ какое-то более менее конкретное техническое решение, которое, очевидно, должно существовать, мы обычно ожидаем чтобы он фактически дал подтверждение и недостающие детали. Но мне при общении с ИИ-агентом, в первую очередь интересно, сможет ли агент в ответ на некоторый сложный вопрос заставить меня (спрашивающего) изменить точку зрения то есть фактически опровергнуть исходную посылку-гипотезу на которую, технический вопрос, так или иначе всегда опирается! По моему это основной признак интеллекта — свобода не только отстаивать свою точку зрения, но и пытаться «заразить» этим собеседника. Так получилось, что у меня сложились практически идеальные обстоятельства для такого эксперимента. Я в принципе знал идеальное решение с самого начала, но в повседневной рутине оно было скрыто множественными наложениями от текущей работы. По той же причине занятости текущей работой я не мог в полной мере сосредоточиться (а главное не старался) чтобы достать и отряхнуть от наложений идеальное решение, а начал сессию с ИИ агентом чтобы в том числе посмотреть насколько эффективной является его помощь в сложных вопросах, по которым невозможно сформулировать какой-то простенький промт, но которые требуют итеративной сессии вопросов-ответов уточняющих вопросов, разъясняющих вопросов-исправляющих вопросов, … Первую часть общения я описал как смог в предыдущей статье . В этой будет то что, как мне кажется, можно именовать окончанием — подведением итогов с ответом на мой вопрос который ИИ-агент охарактеризовал так: Это отличный, глубокий вопрос, который бьет прямо в особенности того, как устроены большие языковые модели (LLM) и как у нас замыливается «цифровой глаз». ... Дисклеймер: редактора, корректоров у меня нет, вычитать, нормально, столько текста я вряд ли в состоянии. Но начать я хочу с более детальной формулировки задачи.
https://habr.com/ru/articles/1063066/
#ииагенты #ииассистент #с++ #с++_программирование #strong_type_name #singleton #llmагент
-
Путеводитель по EASTL
Это вторая часть статьи Путеводитель по чужим STL , возможно будет и третья про разные трюки-хаки с контейнерами, как наберется материал. Стандартная библиотека плюсов оказалась почти непригодной для игровой разработки и поняли это практически сразу, как попытались её использовать. Крупнейший на тот момент издатель Electronic Arts стал самым известным примером реализации стандартной библиотеки для разработчиков игр (но конечно же были и другие, менее именитые), и силами команд нескольких студий под руководством Paul Pedriana это было претворено в жизнь. Корни EASTL уходят в Maxis к 1998-му году, когда Пол работая над SimCity 3000, выступал на GDC с докладом «High Performance Game Programming in C++» про кастомные контейнеры, стоимость вызовов и замеры производительности. Единой EASTL тогда ещё не было, но подход, из которого она потом выросла, виден уже там. До консолидации, даже внутри одной студии, могли существовать несколько параллельных STL-реализаций, разработанных под разные игры, платформы и инструменты. Рискну предположить, что самой полной была реализация от Maxis, как одной из ведущих студий, а в других командах были поменьше, каждая со своими допущениями. Он же в статьях и докладах упоминал, что EASTL была синтезом практик из этих внутренних вариантов, а не работой одного человека с нуля, и в основе большой EASTL лежит коллективный опыт нескольких инженерных команд, даже если формальным автором финальной публичной версии и статьи остался он один. Конкретные имена соавторов отдельных модулей (аллокаторов, фиксированных контейнеров и т.д.) указаны в репо, но слава досталась Полу.
https://habr.com/ru/articles/1058152/
#с++ #с++_программирование #игры_и_игровые_приставки #разработка_игр
-
Как я стал разработчиком и что бы сделал иначе, начиная путь заново: история студента онлайн-магистратуры ИТМО
Привет, Хабр! Меня зовут Влад Лундышев, мне 23 года, я учусь в онлайн-магистратуре ИТМО в партнёрстве с Яндекс Практикумом на направлении «Фронтенд-, бэкенд-разработка и ИИ-решения» и параллельно работаю Python-разработчиком. Если бы несколько лет назад меня спросили, что самое сложное на пути в IT, я бы ответил: изучить язык программирования и алгоритмы, освоить сложный стек. Сейчас я думаю иначе. Самым сложным оказалось найти первую работу, научиться взаимодействовать с командой и выстроить систему развития, которая не приводит к выгоранию. В этой статье я расскажу, какие подводные камни встретились мне на пути и что я бы посоветовал себе самому несколько лет назад.
https://habr.com/ru/companies/yandex_praktikum/articles/1062358/
#backend #яндекс_практикум #магистратура #итмо #с++ #python #онлайнобразование
-
На дворе C++23, а заставить компилятор проверять код всё ещё помогает только ассемблер
Казалось бы, современный C++ дает нам море инструментов для контроля кода на этапе компиляции: static_assert , концепты, constexpr всё, что только можно. Но что делать, если вам нужно заставить разработчика вызвать обязательную функцию инициализации инфраструктуры тестирования для библиотечных классов , а проект собирается под ARM с агрессивным -O2 -Os -flto=auto в недрах Yocto/OpenBMC? В этой статье я расскажу, как попытка добавить удобный режим тестирования для датчиков которые используют header-only библиотеку столкнулась с невероятно умным оптимизатором GCC 14.2, и почему в эпоху мегабайтных исходников нам всё ещё приходится спускаться на уровень инлайн-ассемблера, чтобы просто заставить линкер выдать ошибку для не корректного кода (для определения правила использования хидера).
https://habr.com/ru/articles/1058316/
#linker #c++20 #c++23 #с++ #компиляция #статическая_типизация
-
[Перевод] Очередная библиотека для парсинга аргументов командной строки на C++. Встречайте FancyArgumentParser
Встречайте FancyArgumentParser Парсинг аргументов командной строки в C++ нередко превращается в набор громоздких решений или самописных костылей. Я решил упростить эту задачу и написал FancyArgumentParser — небольшую библиотеку для обучения и пет-проектов. В статье рассказываю, как она устроена, чем удобна и как быстро подключить её к своему проекту.
https://habr.com/ru/articles/1060714/
#командная_строка #с++ #с++11 #с++20
-
Все там будем…
...или почему игровые движки всегда заканчивают одинаково. Вы задумывались когда-нибудь о том, что самый дорогой движок в индустрии написан так, что его проще выбросить и написать заново, чем понять и починить. Или что самая успешная студия десять лет жила на коде, который сами авторы называли «отколбашенным» и в русском языке есть более подходящее понятие, начинается на г... заканчивается на ...код. А правильный с точки зрения архитектуры движок умирает на безвестности, потому что деньги у компании на его развитие закончились. Если не узнали примеры, то в конце статьи будет пояснение. Любой движок, на котором есть "живые" игры проходит через четыре стадии: «хоть както, работает», «работает, но стыдно показать», «не стыдно показать, но никто не знает как работает», и «работает на отдельном языке, который мы сами же и придумали». Потом круг замыкается, и всё начинается новый виток истории, потому что команда осознает, что дальше так жить нельзя. Сразу оговорюсь, что это во многом пересказ чужих мыслей, докладов с GDC, лекций про паттерны, и общение с коллегами из больших студий. Отсылка к словам и блогам двадцатилетней давности тут не для ностальгии, а для дела, потому что в интернете информация живёт недолго, блоги нулевых уже наполовину выпилены, а выводы пятнадцатилетней давности до сих пор актуальны до неприличия.
https://habr.com/ru/articles/1054498/
#с++ #программирование #разработка_игр #игры_и_игровые_приставки
-
Парсер C++ на своем DSL: попытка обогнать компилятор
Проекты растут. Кодовая база растёт. Время компиляции растёт вместе с ними и переходит все границы разумного. В какой-то момент я решил: а что если попробовать написать свой компилятор? Пока только для разработки, не для прода . На замену Clang++/G++/CL.EXE. Эта статья — о первом шаге на этом пути. О парсере C++, который я написал на своём DSL специально сделанном для этого изначально. Матчинг запущен? Кооперация предложена?
https://habr.com/ru/articles/1058150/
#С++ #компиляторы #Парсеры #генераторы_парсеров #разработка #алгоритмы #open_source #C #g++ #clang
-
DIY и C++ в системе охлаждения кур
Расскажу о проблеме, которая возникла после запуска системы охлаждения куриных тушек, и как проблема была решена.
-
Жертвы чистого кода
В индустрии разработки игр (а может софта и вообще) живёт очень удобная идея, которой многие оправдывают лишние слои логики и абстракции. Звучит она примерно так: «Я хочу, чтобы сам процесс создания игр был проще, приятнее и продуктивнее и готов пожертвовать 10% производительности ради этого» - Тим Суини. Аргумент хорош, обещает за небольшую цену красивых абстракций, паттернов и фичей языка позволить программисту быстрее производить "плохой" код, плохой в смысле медленный, но который делает ту же полезную работу, что и альтернативный хороший, но нечитаемый и сложный для понимания. Для бизнеса это выгоднее, хотя по моему опыту, бизнесу глубоко пофиг на количество написанных конкретным Джоном, Ваней или Вапуром строчек кода, его сложность или наличие в нем астракций, там совсем другие метрики "хорошести", пусть и в ущерб качеству итогового результата. Сразу оговорюсь, что под "плохим кодом" я не имею в виду то, что программист видит у себя в редакторе. Там как раз может быть красота, ровные отступы, говорящие имена, абстрации и документация. Но я говорю о реальном коде, который фактически крутится на процессоре или видяхе у игрока, и который превращается в просадки фреймрейта, в полминуты загрузки уровня и в взлетающие вентиляторы. Статья родилась после очередного приступа клинокодомании в отдельно взятой студии, когда кто-то в очередной раз увидел и притащил всем известную книгу Мартина о достоинствах этой самой клинокодии. Но "Clean Code", тот что с заглавной буквы и тысячными тиражами, вовсе не «чистый код» в бытовом смысле, потому что Мартин придумал этот бренд, ярлык, и несколько лет пестовал его на конференциях, связав свое имя и это понятие. Правильнее было бы называть это "стиль мистера Мартина" или "стиль Дядюшки Боба", и тогда половина споров о важности книги отваливается сама собой, потому что спорить приходится уже не про абстрактную "чистоту", а про конкретные наборы приёмов конкретного автора. Та дискуссия с технической стороны так и не получила внятных результатов, потому что на третьем круге обсуждения в ход шла риторика и подмена понятий вроде «clean» (хороший, годный), который начал превращаться в «Clean» (по методичке), и обратно.
https://habr.com/ru/articles/1054314/
#с++ #разработка_игр #программирование #игры_и_игровые_консоли
-
Stream compaction на NEON. Векторизуем copy_if
Как разогнать copy_if на NEON в 30+ раз без единой ветки в горячем цикле — эмулируем compress инструкцию, которой в NEON нет, через table lookup и немного битовой магии.
-
Как начать программировать на C++: обзор бесплатной части курса
C++ — один из самых востребованных языков в мире: на нём пишут игры, операционные системы, браузеры, высоконагруженные сервисы и даже микрокод для медицинских устройств. Язык входит в тройку самых популярных по индексу TIOBE, а создать «убийцу C++» пока не удалось никому — попытки были. При этом язык это непростой — с нуля к нему бывает сложно подступиться. В Яндекс Практикуме у курса
https://habr.com/ru/companies/yandex_praktikum/articles/1054242/
#с++ #яндекс_практикум #курсы_по_с++ #онлайнкурсы #онлайнкурсы_по_с++
-
Худший язык программирования всех времён /s
Есть на ютубе видео на пятьдесят минут с гордым названием «худший язык программирования всех времён» . Не удивлюсь, если вы подумаете, что оно про C++. Оно действительно про плюсы и я его смотрел где-то с полгода назад, ну как смотрел... пробежался на x2 с перемотками, мало ли что обиженный джун там наговорил, но добрый @alyokhin опять про него напомнил, и теперь я его посмотрел полностью. И знаете что самое неприятное? Если убрать интонацию обиженного джуна и оставить только аргументы, то процентов семьдесят там будет правды. Не «спорно», не «зависит от контекста», а буквально правда, которую любой разработчик, проведший с языком пару лет, подтвердит вам не задумываясь. Парадокс в том, что это видео сняли про язык, на котором написана половина мира вокруг нас. Браузер, в котором вы это читаете, движок игры, куда уж без игр в моих статьях, в которую вы вчера играли, прошивка железа, на котором всё это крутится, и компилятор, которым собрали и браузер, и движок, и прошивку. Жанр «почему C++ ужасен» на Хабре выжжен дотла и про Init-зоопарк, перегруженный static , vector названный неправильно, std::move который не move, супер медленный regex, медленный unordered_map вы всё читали раз по двадцать. Сам по себе список этих болей давно не новость, от себя добавлю, что все жалобы и примеры ниже - это следствия одного решения, и я к нему приду. Или открывайте спойлеры, там скрыта история, почему каждая часть языка получалась так, как получалась. С++ is the best ever programming language
https://habr.com/ru/articles/1047890/
#с++ #программирование #ненормальное_программирование #разработка_игр
-
Лучший способ изучить разработку с Qt
Когда-то изучить Qt было относительно просто: достаточно освоить C++, разобраться с сигналами и слотами, научиться размещать виджеты на форме — и уже можно было писать серьезные приложения. Сегодня экосистема Qt стала значительно шире. Помимо базовых компонентов разработчику приходится работать с многопоточностью, сетевым взаимодействием, моделями данных, мультимедиа, графикой, QML и множеством других модулей, а значит, растет и объем необходимых знаний. Проблема в том, что эти знания зачастую разбросаны по документации, отдельным статьям и книгам, каждая из которых рассматривает лишь часть общей картины. Поэтому найти издание, позволяющее последовательно пройти весь путь — от первой программы на C++ до разработки полноценных приложений на Qt, — становится все сложнее. Именно такую задачу решает новая книга Дмитрия Осипова « А теперь - подробнее
https://habr.com/ru/companies/bhv_publishing/articles/1054226/
#С++ #qt #программирование #разработка #обучение #книги #бхв #qml #фреймворк #framework
-
Как «ужать» мегаполис до размеров iPhone 4
Помните времена, когда трава была зеленее, мобильный интернет помегабайтным, а Apple осваивала непаханые поля смартфоно-игровых ферм? Начало 2010-х было очень интересным временем, когда мобильные студии создавали целые новые жанры, пытались перенести или адаптировать старые концепции и игры, попутно решая задачи, от которой у десктопного разработчика начинал дергаться глаз. Вот и EA решили взять культовые франшизы SimCity и The Sims со всеми их терабайтами ассетов, сложнейшей симуляцией дорог, пробок и отдельных симов, и попробовать затолкнуть это в карман. В кармане у пользователя тогда лежал условный iPhone 4 или 5 с уже тогда куцым бюджетом оперативной памяти в районе 100–300 МБ на всё про всё, но айфоновладельцы были "платящей" аудиторией, поэтому игровое подразделение метило в основном в них. Как не превратить смартфон в обогреватель и словить ООМ в первые минуты игры? Выкинуть честную симуляцию на помойку, превратить симов в конечные автоматы, а город сделать хитрой иллюзией из текстурных атласов и таймеров . Раскажу немного как устроены SimCity BuildIt и The Sims Mobile с инженерной изнанки, кода почти не будет, да он и не нужен тут для понимания, а еще будет немного грустинки по российскому подразделению EA, и фотки с закрытия офиса в 2016.
-
Создаем потокобезопасную очередь с условными переменными: «академический» пример против реальности
Представьте, что вы едете в ночном поезде. Чтобы гарантированно выйти на нужной станции, придется не спать всю ночь и внимательно отслеживать остановки. Свою станцию вы не пропустите, но сойдете с поезда уставшим. Другой способ: узнать из расписания предполагаемое время прибытия поезда, поставить будильник на нужное время с небольшим запасом и лечь спать. Этого вполне достаточно, чтобы не пропустить свою станцию, но, если поезд задержится, пробуждение окажется слишком ранним. Идеальным решением было бы лечь спать, положившись на то, что кто-нибудь или что-нибудь разбудит вас незадолго до реального прибытия поезда на нужную станцию... Какое отношение этот пример имеет к работе с потоками в программировании? Дело в том, что решить задачу синхронизации конкурентных операций можно также несколькими способами, близкими к ситуации выше. Меня зовут Александр, я разработчик на С++ в YADRO, и в этой статье я разберу несколько вариантов эффективной организации ожидания потоков.
https://habr.com/ru/companies/yadro/articles/1051850/
#с++ #очереди #мьютексы #consumer #задача #многопоточность #producer
-
НЕкурс про создание собственного языка программирования: вдохновляемся неожиданными открытиями, чтобы сделать свои
В этой заметке мы разберём, что такое экспертиза и в чём её суть. Она бывает разной глубины, сферы и предназначения. Экспертиза не может существовать без теоретических знаний, опыта и, конечно же, не рождается там, где нет трудностей и ошибок. У каждого человека она уникальна.
https://habr.com/ru/companies/pvs-studio/articles/1050964/
#с++ #парсер #язык_программирования #курсывебинары #экспертиза #интерпретатор #интерпретаторы
-
Путеводитель по чужим STL
Надеюсь вам понравилась статья про работу с памятью на консолях , где каждый ездил на том велосипеде, который сам же и придумал, попробую рассказать про зоопарк теперь уже стандартных библиотек. Стандартных в отдельной студии или конторе, потому что у соседней будет свой стандартный стандарт. Забавно что любовь прикрутить очередную погремушку к своему велосипеду становится тем сильнее, чем становится крупнее контора, поэтому приходя в игровую студию есть очень немаленький шанс, что стандартный STL у неё нестандартный, обёрнут или вовсе запрещён религией кодстайлом. EA, Facebook, Google, Adobe, LLVM и рядок компаний поменьше тратят человеко-десятилетия в поисках ответа на главый вопрос жизни, Вселенной и всего такого «почему std:: это медленно, непредсказуемо и жрёт память». По аналогии с прошлой статьей вам не потребуется знать стандарт наизусть, а будет достаточно понимать, что такое указатель, чем вектор отличается от дерева и почему промах в кеше это дорого, а дальше я пройдусь по разным стандартным библиотекам и про каждую немного расскажу, что это, зачем оно появилось и где об него можно больно удариться, потому что про вот этот последний пункт обычно забывают "продаваны" и прочие студийные еванглелисты, когда расказывают какое там всё красивое, легкое и с++двадцатое.
https://habr.com/ru/articles/1042198/
#с++ #с++_программирование #ненормальное_программирование #игры_и_консоли
-
Мы вас видим
Есть такая забавная категория людей в разработке, давайте назовём их IT-волки. Это те самые ребята, у которых в 26 лет уже 12 лет опыта, в 27 два проекта и архитектура уровня «я тут всё с нуля поднял», а в 28 управление двумя командами под миллион MAU. Иногда смотришь такое CV и думаешь - ну всё, сейчас придёт человек, который видел боль, огонь и сломаный прод, а потом начинается интервью. И очень быстро становится понятно, что дело вообще не в синтаксисе или знаниях фреймворков, иногда это могут быть идеальные знания, что тоже пугает. Знания конкретных фреймворков, это вообще не проблема и можно забыть название паттерна, потому что этих самых паттернов овердофига и можно перепутать детали. Это нормально, у всех бывает, интереснее другое. Когда начинаешь спрашивать про реальные решения, про ошибки, про “что вы делали”, про “почему вы это сделали именно так”... вот тут часто начинается тишина.
https://habr.com/ru/articles/1050320/
#с++ #разработка_игры #управление_персоналом #управление_проектами
-
Динамический полиморфизм против std::variant на указателях: Разрушаем мифы о скорости std::visit
В экосистеме современного C++ прочно укоренилось мнение: классический динамический полиморфизм через виртуальные функции ( vtable ) — это устаревший, медленный и недружелюбный к кэшу процессора механизм. В качестве «серебряной пули» модно предлагать связку std::variant и std::visit . По интернету кочуют статьи, утверждающие, что std::visit выполняет диспетчеризацию за фиксированное время O(1) и полностью уничтожает старый добрый ООП-подход. Но в таких сравнениях авторы часто совершают методологическую ошибку: они противопоставляют вектор указателей std::vector<Base*> вектору сырых объектов std::vector<std::variant> . Разумеется, std::variant побеждает, но не из-за механики вызова, а благодаря стопроцентной локальности данных в кэше процессора. Давайте снимем розовые очки, уравняем условия и изолируем саму механику вызовов. Представьте реальный сценарий: объекты тяжелые, создаются динамически в разное время и разбросаны по куче (Heap), а мы оперируем массивами их адресов. Мы столкнем лоб в лоб std::vector<Base*> и std::vector<std::variant<TypeA, TypeB, TypeC>*> в условиях раздельной компиляции (когда оптимизатор -O2 не видит тела функций и не может применить тотальный инлайнинг).
-
C++101
Про C++ часто шутят, что любую вещь можно сделать пятью разными путями, четыре из которых компилируются, три работают, а два правильные, но один зависит от фазы луны. Часто такие шутки и идиомы откладываются в коллективной памяти сообщества какой именно из этих путей правильный в каждой конкретной ситуации. Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr , ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые кострукции, которые в более поздниях стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх. Разработка игр тут не случайно, потому что игровой движок это обычно место, где абстракции встречаются с профилировщиком, и проигрывают ему чаще, чем хотелось бы. А легаси паттерны цветут и пахнут из-за чьих-то забытых в углу костылей, но большинство вещей вполне правильны, применяются и спасают от ошибок. Многое из этого спрашивают если не дословно, то хотя в паре слов, хорошие лиды на собесе, перед тем как позвать вас в команду, и просто взяв рандомо 5-6 пунктов можно составить впечатление, сталкивался ли новый человек с определенными проблемами. Когда я собирал оглавление Game++ , раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе. Перед вами то, что могло бы стать половиной Game++ , но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе. Вероятно вам потребуется вспомнить некоторые правила вывода шаблонов, и что такое конструктор и деструктор, чем стек отличается от кучи, что у объекта есть время жизни, но это не точно. Я также намеренно убрал обработку краевых случаев и разные проверки из кода, которые в реальном коде заняли бы половину всего текста и утопили бы саму мысль в деталях. Паттерн механизма в моем случае важнее конкретной реализации, и почти каждая из них существует в десятке вариаций под разные компиляторы и стандарты.
https://habr.com/ru/articles/1044450/
#с++ #с++_программирование #игры_и_консоли #разработка_игр
-
Почему игровой GUI пишут заново (Ч.1)
Если показать любому игровому программисту лекции про пользовательский интерфейс года эдак 2006, а потом показать ему что он наклодовал в современной игре, то он узнает в них почти всё, но с небольшими оговорками. Поменялись названия API и язык кодогенерации, но архитектура и основные идеи остались те же: дерево контролов, свойства с рефлексией, связи между свойствами, шаблоны, абстракция над движком и вечная война за пиксель-в-пиксель. Пользовательский интерфейс в играх это место, где встречаются все худшие архитектурные требования сразу, на них накладываются требования дизайнера UI, который сидит через стол и просит, чтобы окно появлялось «вот так с анимацией», причем «вот так» зависит выпил ли он чашку кофе или еще нет. Вечером приходит художник, который нарисовал кнопку в фотошопе и хочет, чтобы на экране она выглядела пиксель-в-пиксель, и вы обязаны учесть эти требования, потому что в этой цепочке принятия решений художник стоит ближе к финальной картинке. А еще есть программист игровой логики, который не хочет знать, как называется конкретный лейбл, и не должен этого знать. Под конец приходит локализатор, который превратил «1 enemy / 2 enemies» в «1 враг / 2 врага / 5 врагов» и зависимость от рода. Иногда заскакивает инженер по портированию, которому надо то же самое окно крутить на PC, консолях или мобилках с разными разрешениями и соотношениями сторон, ну на него пофиг, он сам себе программист и если что, допишет код. И всё эти требования должны как-то жить вместе. Большая часть студий начинала с написания системы GUI «по месту», т.е. для конкретной игры, под конкретный рендер, с захардкоженной раскладкой, а когда выходила следующая игра, выяснялось, что вытащить старый GUI почти невозможно. Такой UI насквозь срастается с рендером, инпутом, звуком и игровой логикой и каждый следующий проект начинается с фразы «давайте сделаем нормально один раз», и каждая следующая итерация показывала, что «нормально» это не одна задача, а много и одновременно. Не переключайтесь, будет еще вторая часть про то как этот самый UI мучали от игры к игре... Погрузиться в глубины
https://habr.com/ru/articles/1039592/
#с++ #с++_программирование #программирование #игры_и_игровые_приставки #никто_не_читает_теги