C++ *

Предыдущая тема

Обзор игры на SFML С++. Как клонировать репозиторий и собрать проект с помощью СMake. Обзор классов игры "Пчела на работе".

Что-то часто стал заглядывать в профиль после каждой новой публикации. Так вот я и решил сделать табло, которое стояло бы на столе, и показывало место в рейтинге, карму, ну и само значение очков рейтинга.

В первой части статьи мы обсуждали разработку самого нижнего слоя СУБД Boson - CachedFileIO. Как упоминалось, статистика такого явления как Locality of Reference говорит о том, что в реальных приложениях ~95% запросов к данным локализованы в 10-15% базы данных. При этом среднее соотношение чтения/записи - 70%/30%. Это делает эффективным использование кэша (cache) работающего на основе алгоритма Least Recently Used (LRU). Реализовав его, мы получили 260%-600% прироста скорости чтения при 87%-97% cache hits.

Следующим после кэша слоем СУБД Boson является хранилище записей RecordFileIO. Это уже первый прообраз базы данных, который начинает приносить прикладную пользу. Сформулируем верхнеуровневую спецификацию требований:

В этой статье я собираюсь провести тест производительности на компиляторе Microsoft и компиляторе GCC, чтобы ответить на простой вопрос: окупается ли политика выполнения?

Lock-free структуры данных в общем и целом неплохо описаны в различной литературе, но на мой взгляд порог вхождения в эту тему высок. Приведу простой кейс использования одной из разновидностей данной технологии под названием RCU (Read–Copy-Update). В двух словах, это механизм неблокирующего обновления структуры данных у которой много читателей и всего один писатель. Wikipedia.

В предыдущей части цикла я описал способ вызова слота посредством очереди обработки сигнально-слотовых соединений Qt (она же очередь событий). Но совсем забыл про такую штуку, как QMetaObject::invokeMethod. А ведь эта штука позволяет добиться такого же эффекта (вызов метода в потоке-владельце QObject), но без необходимости создания сигнала.

Принялось решение добавить регулярные выражения в свой язык программирования. По началу я подумал, что мне совершенно незачем в них разбираться и в интернете, наверняка, уже есть полно готовых библиотек. Стал искать, нашёл какие-то осколки кода на С++, которые ничего не дают. Пришлось самому разобраться, что такое регулярные выражения тут. Ради спортивного интереса, я решил сделать свою библиотеку на С++.

Стал делать и подумал, а почему бы мне не добавить туда своих тараканов. Я решил добавить две конструкции:

{namesubexpression} - вызов под выражения по имени "namesubexpression",
($namesubexpression:BodyExpression) - описание под выражения с именем "namesubexpression".

Само описание под выражения может встречаться в любом месте структуры регулярного выражения и игнорируется при поиске, подобно закоментированым: (#MeComment).
Сразу же возникает проблема бесконечной рекурсии.
Вот пример рекурсивного регулярного выражения, который недопустим: ($E:{E}){E}

Конечно, я сделал стадию валидации и такие поисковые конструкции просто не допустятса в поисковую машину. Также валидацию не пройдет выражение, которое содержит в себе вызов не описанного под выражения.

Вот пример текста, который можно спарсить рекурсивным регулярным выражением (РРВ): [[[[[A]]]]]
А вот его РРВ: ($RRE:\[({RRE}|A)\]){RRE}

Я также решил добавить три зарезервированные конструкции:
{:String} соответствует выражению: (("(\\.|[^"])*")|('(\\.|[^'])*'))
{:Digit} соответствует выражению: (-?[0-9]+.?[0-9]*[Ee]?-?[0-9]*)
{:Name} соответствует выражению: ([A-Za-z][A-Za-z0-9]*)
Но их поисковая система не использует структурные элементы аналогичных выражений, а организованна встроенным машинным поиском, который работает значительно быстрее и возвращает одну целую строку текста, в которой содержится всё тело найденного соответствия а не части для каждого компонента в аналогичных регулярных выражениях.

Кодогенератор это программа, которая на основе исходного кода или какого-нибудь файла настроек генерирует вспомогательный код, который потом компилируется вместе с исходным кодом. Это нужно, чтобы не писать boilerplate-код, а также для получения дополнительных возможностей языка.

Я делаю расширяемый кодогенератор для C++, в котором можно реализовать много полезного. Примеры модулей: перевод значений enum в строку и обратно, перевод структуры в JSON и обратно, декларативный веб-сервер, система слотов и сигналов, свой динамический полиморфизм, генератор кода для тестов...

В этом обзоре будет showcase, сравнение с другими кодогенераторами, как работают модули, как сделать свой модуль, и как подключить кодогенератор в свои проекты.

Давным-давно, когда деревья были маленькие, дискеты большие, а трава зеленая, все писали на языках низкого уровня. В этих языках все было целыми числами. Переменные были числами, массивы были и структуры были просто адресами (числами) и смещениями (тоже числами). Даже если указывали тип данных, то он определял только размер памяти для значения.

В эти старые добрые времена было очень мало причин почему программа не могла продолжить работу. Например деление на ноль, неправильное обращение к памяти (например обращение по адресу равному нулю) или неправильная инструкция процессора (это когда уже совсем все плохо). Если что-то такое происходило операционная система без капли смущения грохала вашу программу.

Чтобы программа не грохалась, а выдавала осмысленное сообщение и давала возможность продолжить работу, надо было добавить проверку.

Во всех предыдущих статьях мы рассматривали лишь самый простой пример — сериализованный вывод сообщений на экран в отдельном потоке.

Пришло время, наконец, сделать что-то более реальное и существенное, пусть и не очень сложное. И этим будет менеджер http запросов.

Статья выпущена как дополнение к предыдущей и показывает, как можно сделать Active object, работающий асинхронно в среде Qt, но при этом не использующий события.

Должен признать, что в некоторые из предыдущих лет C++ мог ощущаться немного «скучным» и «стабильным». Новые фичи, новый стандарт каждые три года, встречи, конференции... обычная жизнь (не считая некоторых дополнительных событий с в мире, экономике и эпидемиологической ситуации). Прошедший год отличается, потому что выглядит как «переломный» в истории C++... и кто знает, куда это заведёт нас.

Давайте вспомним некоторые вещи, случившиеся в прошедшем году.

Вступление

Привет, друзья! В этом цикле статей я максимально подробно буду рассказывать о процессе разработки игры на UE – SuperIndustry. Вы сможете на моем примере познать процесс разработки 3D игры на UE. Вкратце про игру: Представьте гибрид Oxygen not included и Satisfactory, в далеком будущем и на специфичной экзо планете. В игре будет глубокий сюжет, который будет повествоваться через своеобразный дневник. Главная цель – улететь с планеты (остановиться на достигнутом) или же продолжить общение с высшим Существом и узнать, что будет дальше.

Предыдущая часть.

Пришло время написать вторую часть статьи. На этот раз мы рассмотрим нечто, к чему вы скорее всего придёте, работая над многопоточным кодом с использованием Qt.

В продолжение к прошлой статье решил пощупать и Attiny10. Ну меньше уже точно ничего нет. Если и есть такое извращение с 4 ногами, я о нем не знаю, точнее не нашел.

Тут у нас полноценный МК, в корпусе SOT-23! И задачи на нем решать можно вполне серьезные. Собрав схему на макетке, с МК на адаптере и модулем дисплея я было обрадовался, но готовая плата работать отказалась...

Предыдущая тема

Используя графические объекты библиотеки SFML С++, создаём прототип игрового меню. Для практического использования, игровое меню разработано в виде класса GameMenu, который можно подключить к своему проекту через заголовочный файл.

На дворе четыре часа ночи. В душе не понимаю, зачем я это пишу, чего я хочу этим добиться, и т.д. Если вкратце, то это будет цикл статей из разряда "хоба, как могу", причём это самое "хоба" зачастую слишком очевидно и элементарно, да и далеко не всегда полезно, особенно, в контексте философии Qt. Так что это будут просто "размышления обо всём".

Развитие технических конструкций или же программных систем зачастую напоминает эволюцию живых организмов. С тем отличием, что происходит быстрее и гораздо лучше задокументировано. Можно наблюдать постепенное усложнение, появление новых механизмов/алгоритмов по мере появления новых технических возможностей, комбинирование разных механизмов, исчезновение тупиковых ветвей ... В конце концов это приводит к балансу на пределе физических возможностей и, глядя на результат, уже непонятно, как вообще такое могло появиться на свет, сколько пядей во лбу требуется для общего понимания конструкции.

Аллокатор памяти в С - именно тот случай, когда при попытке ознакомиться с его современным устройством возникает стойкое желание остановиться, мысленно поблагодарить авторов и далее обращаться как с черным ящиком. Если же в читателе сильна любознательность, и/или есть желание постигнуть тайное знание, которое даст ощущение понимания странного поведения программ в нетривиальных случаях, добро пожаловать под кат.