Данная статья служит шпаргалкой при написании классов с различными перегрузками операторов на примере тривиального класса строки (и ещё нескольких). Описанное здесь позволяет избежать копирования кода из одного конструктора или оператора в другой, что значительно снижает вероятность появления ошибок, но может привести к незначительному уменьшению производительности.
В данном уроке, я опишу формат архивов игры, напишу код, для загрузки файлов и выведем первый спрайт. Я расскажу и покажу, как движок работает с файлами, загружает графику и рисует спрайты игры. Так же расскажу о тестых для игры, которые ускоряют написание кода и его изменение.
Один из моих старых постов о strlcpy недавно вызвал обсуждения на различных форумах. Вероятно, с этим как-то связан выпуск новой версии POSIX. Многие авторы приводили один контраргумент, который я слышал и раньше:
«В общем случае, когда исходная строка умещается в конечный буфер, strlcpy будет обходить строку только один раз, а strlen + memcpy будут обходить её дважды».
Под этим аргументом скрывается допущение о том, что однократный обход строки выполняется быстрее. И, честно говоря, это вполне разумное допущение. Но справедливо ли оно? Об этом мы и поговорим в статье.
Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:
«Возьмём для примера этот код в локальной области видимости функции:
int a;
a = 5;
Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".
Однако я убеждён, что инициализация происходит в строке 2, потому что [в разных хороших книгах по C++] инициализация определяется как первое существенное значение, попадающее в переменную.
Можете ли вы сказать, какая строка считается инициализацией?»
Отличный вопрос. На Cppreference написано правильно, и для всех классовых типов ответ прост: объект инициализируется в строке 1 вызовом его стандартного конструктора.
Но (а вы ведь знали, что будет «но») для локального объекта фундаментального встроенного типа наподобие int ответ будет... чуть более сложным. И именно поэтому Сэм задал этот вопрос, ведь он знает, что язык достаточно свободно обращается с инициализацией таких локальных объектов по историческим причинам, имевшим в то время смысл.
Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»
Всем привет. Сегодня я хочу рассказать об использовании WASM с C++ и разберу, как взаимодействовать с этим всем делом через JavaScript.
Материал предназначен для новичков в данной теме.
Привет, Хаброжители!
Попросили инженеров YADRO поделиться избранными материалами про алгоритмы и структуры данных для «плюсовиков». Вспомнили и «классику» вроде книги Никлауса Вирта, и более современные источники, а также рассказали, почему стоит посвятить им время.
Статьи, лекции и курсы из подборки помогут опытным специалистам «вспомнить все» перед собеседованием или погрузиться в тему алгоритмов, если вы пока в ней не сильны.
Новый синтаксис для циклов for в C++ появился уже давно - более десяти лет назад в стандарте C++11. Идея, скрывающаяся за этим синтаксисом, не является сколь-нибудь запутанной, и практически все, кто интересуются новыми свойствами языка, быстро разобрались с тем, как этим синтаксисом пользоваться и, что важнее, как создавать свои типы, совместимые с синтаксисом range-based for. Однако, как мне кажется, именно в вопросах взаимодействия с пользовательскими типами спецификация range-based for содержит несколько интересных деталей, лежащих практически на поверхности, которые остаются незамеченными просто потому, что идиоматические подходы прекрасно обходятся и без них. Возможно, кому-то будет интересно взглянуть на них повнимательнее.
Приветствую, Хабравчане!
Начинаю цикл статей, по воссозданию движка моей любимой игры Arcanum. Цель, написать движок Arcanum'а и в каждой статье шаг за шагом добавлять функционал с описанием кода, принятых решений, прогресса.
"Как будто у Unreal и Unity родился ребёнок" — такое трогательное описание дали этому движку в GameDev-сообществе. Эта фраза не только мило звучит, но и точно передаёт его суть, ведь движок действительно задумывался как нечто среднее между Unity Engine и Unreal Engine.
Свет видел много любительских реализаций std::tuple, и реализация своих велосипедов — наверное, это действительно действенный способ обучения: вряд-ли можно сказать, что ты что-то по-настоящему понимаешь, если не можешь объяснить, как это что-то устроено.
Многие пытливые умы на протяжении десятилетий задавались вопросом: как же реализован std::tuple, как мне реализовать свой тупль (кортеж)? [1]
И немало было дано ответов на такие вопросы и написано статей ([2]). Однако я берусь утверждать, что все они имеют один фатальный недостаток! Конкретнее, они все рассматривают в основном лишь один (и при этом неэффективный) способ реализации: с помощью множественного наследования или рекурсивного инстанцирования, имеющий в свой очередь множество своих недостатков, главный из которых — неэффективное использование памяти.
В то время как современный C++ позволяет реализовать тупль гораздо проще (без обилия шаблоноты) и эффективнее.
Согласно описанию,
Tree-sitter — это инструмент для генерации синтаксических анализаторов и библиотека инкрементного синтаксического анализа. Он может создавать конкретное синтаксическое дерево для исходного файла и эффективно обновлять синтаксическое дерево по мере редактирования исходного файла.
Но как Tree-sitter справляется с языками, в которых необходима стадия препроцессинга?
В этой статье пойдёт речь о расширении компонента AbilitySysystemComponent, создании способности атаки c комбинацией и добавление этой способности с помощью GameFeatures.
Привет всем.
Я давно занимаюсь разработкой десктопных приложений с использованием Qt и уже наработал некоторые подходы по работе с логами. В данной статье я бы хотел поделиться с сообществом этими подходами, они могут пригодиться в разных ситуациях.
Привет, я Майк.
Недавно я начал работать в компании Manticore на должности Developer Advocate. Я не совсем далёк от ИТ, но сейчас активно осваиваю современные технологии. В этом блоге я буду делиться своим опытом и тем, что узнаю о Manticore. Я планирую вести дневник, где буду рассказывать, что такое Manticore и как с ним работать. Давайте вместе разбираться, как все устроено, выявлять проблемы и взаимодействовать с разработчиками.
Если вам интересно изучать Manticore вместе со мной, я буду держать вас в курсе в:
Разработка игр и их прохождение могут быть невероятно увлекательными и затягивающими занятиями, приносящими огромное удовольствие. Но ничто так не портит впечатление от игрового процесса, как коварно спрятавшийся баг. Поэтому сегодня под нашим пристальным вниманием окажется Open Source движок Godot Engine. Давайте проверим, насколько он хорош, и готов ли он подарить нам незабываемые эмоции от создания и прохождения игр.
Если вы никогда не пробовали смотреть как код на C++ разворачивается компилятором в код Assembly – вас ждёт много сюрпризов, причём, не нужно смотреть какой-то замудренный исходный код полный templates или других сложных конструкций: рассмотрите следущий snippet:
В серии статьей я расскажу о моём процессе создания плагина Combat Abilities System, который расширяет возможности стандартного плагина Gameplay Ability System в Unreal Engine. Мы рассмотрим шаги разработки, архитектурные решения и особенности, которые делают наш плагин уникальным и полезным для создания боевых механик в играх.
