C++ *

Я использую PostgreSQL 12-й версии! На остальных не проверял! Соответственно, он у вас должен быть скачан и настроен для использования.

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

Так делает imgui, равно как и все, кто использует stb_truetype. Сам процесс приятно напоминает процесс наборного производства на физических станках.

Причудливо, правильно, но в то же время напряжно.

Если нам нужно просто вывести какое‑то сообщение для дебага? Нет ли какого‑либо более простого метода?

В данной статье я опишу метод бестекстурной отрисовки дебаг‑текста. Вдобавок, отрисовка будет производиться в один вызов draw.

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

После статьи о книгах для саморазвития gamedev программиста, меня просили больше написать про аишную часть и том, что стоит почитать по этой теме. Для программиста ИИ в игрострое ситуация с книгами схожа, но с несколькими интересными особенностями. Здесь важна не только глубина знаний, сколько наработанность с инструментами, библиотеками и технологиями в целом, а с учетом что новые подходы развиваются с поразительной скоростью, поразительной для игростроя конечно. Казалось только лет 10 назад стали использоваться BT (behavior tree), но и они уже имеют редакцию 4.x (https://www.behaviortree.dev/). Но важно не зацикливаться на затаскивании в проект модных примочек, базовые знания остаются самым важным что можно получить. Это как в притче о удочке — дай человеку рыбу, и он накормит себя сегодня; дай ему удочку, и он будет кормить себя всю жизнь. Удочкой в этом случае выступает знание, как оно работает, а не как можно его использовать.

ИИ до сих пор стоит в игрострое особняком, потому что до сих пор нет стандартов построения игровой логики, каждая из студий решает свои уникальные технические и инженерные задачи, и вынуждена находить баланс между чем-то новым и общей стабильностью игры. Этот путь усеян пробами и ошибками, даже если вы уже прошли по нему в прошлом, и мало кто поможет вам увидеть ошибки заранее, банально потому, что прошел по другому пути, со своими граблями и костылями. Тем хуже когда, именитый разработчик приходит в команду и начинает продавать свои решения и опыт, которые часто не бьются с разработками команды. Но, статья не об этом, а о полезных книгах.

В предыдущей статье было показано, что при решении СЛАУ с симметричной разреженной матрицей наличие лидирующих нулей приводит к уменьшению количества вычислений. В этой статье будет представлен алгоритм, предназначенный для увеличения количества лидирующих нулей данной матрицы. Если переставить i-ую и j-ую строки, а также i-ый и j-ый столбцы, то матрица останется симметричной. Такие перестановки называют симметричными. Они могут менять количество лидирующих нулей и, если их правильно применять, то количество лидирующих нулей можно увеличить. Другими словами, нам надо сделать так, чтобы все ненулевые члены по возможности находились возле главной диагонали. В частности, если известно, что матрица - ленточная, то делать ничего не надо.

Предлагается следующий алгоритм.

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

Таким образом количество нулей в этом столбце будет максимальным. Далее строки в которых были не нули игнорируем. Находим столбец с минимальным числом ненулевых элементов без учёта этих строк и делаем его следующим. И так далее пока не пройдём всю матрицу.

Ниже помимо краткого текстового описания программы приводится много кода на С++, который сам по себе является точным описанием алгоритма.

Все мы знаем, что такое Telegram. Наверняка и вы, читатель, им пользуетесь. Как и в любом другом проекте, в коде Telegram тоже есть баги, и, если вы программист, эта статья специально для вас! Мы проверили исходный код мессенджера и готовы поделиться с вами интересными находками.

Паттерн Команда (Hello World + Undo)

Всем привет. В этой небольшой статье хочу поделиться методом, к которому пришел, когда разрабатывал игру 2D. Та игра, где столкнулся впервые с такими вопросами, натолкнула меня на написание этой статьи и переосмыслении в том, чем я пользуюсь в С++ и как.

Подготовка рабочего пространства

Пользуюсь Линуксом, компилятор 14.2 gcc/g++, cmake>3.27, SDL3, X11.

Друзья! В данной статье мы бы хотели порассуждать на тему использования инструментария языка C в C++, и как это может повлиять на исходную программу.

Ссылки на полезные ресурсы вы сможете увидеть в конце статьи, и обязательно делитесь своим мнением в комментариях, нам будет очень интересно с ним ознакомиться!

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

В статье «Как исследователи нарушают привычные подходы в ИИ, исключая матричное умножение» упоминалось, в частности, что перспективным кажется хранение в нейросетевых матрицах лишь троичных значений: (-1, 0, 1), иначе говоря - тритов. Такие матрицы умножать друг на друга проще. И в моей статье я расскажу, как собственно, матрицы из тритов хранить и умножать.

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

Итак. Пусть у нас есть полиморфная (шаблонная, перегруженная, - неважно) функция f(x).
И мы написали концепт, который говорит, что тип может быть аргументом этой функции.
Назовём его fable, то есть, "f-абельный", или, по-русски, "сказка". (Эта сказка будет страшной).

На C++20 это выглядит очень просто и элегантно. (Без requires в виде шаблонной метафункции это тоже делается, но заметно громоздче).

Я являюсь автором проекта по математическому моделированию прикладной механики и в работе моей программы до 90% вычислительного времени уходит на решение системы линейных уравнений. Цель этой статьи сугубо практическая - найти оптимальный метод решения системы линейных уравнений с точки зрения производительность/трудозатрат для небольшого проекта и рассказать о результате.

В прошлом я уже несколько раз обращал внимание на вычисления на GPU, но всегда что-то останавливало. И вот у меня накопился достаточный практический опыт программирования на C/C++ и наконец дошли руки, чтобы протестировать OpenCL.

Всегда хотел написать о чем-нибудь легком и воздушном, как пишет например @antoshkkaпро userver или о том, как легко и непринужденно обернуть какую-нибудь хрень алгоритм в десяток шаблонов, полить это все std::optional и попивая кофе ждать, когда компилятор соизволит это всё пережевать. Но судьба (а не тимлид, нет, как вы могли такое подумать) постоянно подкидывает задачки, где суровые объятия отладчика не отпускают мечтательную душу программера до поздней ночи, да вечная борьба с компилятором рушит все попытки обернуть результат хрени алгоритма в другой десяток шаблонов. На этот раз судьба ясным июньским утром подкинула забавную задачу - время полной сборки бандла подбиралось к двум часам, да собирать бандлы нынче удовольствие не из быстрых, но посмотрев статистику стало понятно, что ~55% процентов времени тратится на сборку ресурсов: текстур, моделей, локализацию, и тд. Там есть что чинить, но это царство билд-инженеров. Еще 30% или сорок минут тратится на тесты, теперь все что мы насобирали и переконвертили надо проверить, загрузить, пострелять, побегать, монстров поубивать, BT-шки погонять, с этим пусть QA разбираются. А вот оставшиеся 15% или около 15 минут мы занимались настоящей работой, собирали сердце проекта - бинарь. Да норм, у нас всегда так, даже на пустом проекте UE - сказали наши мобильщики и ушли пить кофе на терассу . Но мы же не мобильщики, мы серьезные AAA ребята, у нас свой движок и кастомный пайплайн на билдферме. И потом 15 минут это очень много, даже если у тебя 27к файлов в проекте, айда смотреть куда время потратили.

Друзья! В данной статье мы бы хотели рассказать про кроссплатформенную коллекцию утилитных C++ компонентов CUtils.

CUtils — это довольно полезный инструмент при разработке кроссплатформенного программного обеспечения на языке программирования C++.

Недавно была опубликована статья под заголовком "Глобально оптимальный, восьмой и наиболее быстрый вид интерпретаторов байткода". Несколько тезисов из статьи вызвали у меня сомнения в их справедливости. Об этом я попробовал написать ряд комментариев тире вопросов к указанной статье. Но основной лейтмотив всех ответов сводился к тому - "а ты напиши свою статью". Подход не столько инженерно-научный, сколько детсадовский. Мне бы хватило и содержательных ответов в формате комментариев, но как говорится - уговорили :).

Итак, что же утверждается автором статьи про наиболее быстрый интерпретатор:

В данной статье описан пошаговый процесс разработки служб для операционной системы Windows с использованием языка программирования C++.

В статье будет представлена теоретическая база по работе служб в Windows, рассмотрено их общее устройство и будет реализовано приложение, с помощью которого можно будет устанавливать свою службу, запускать её, останавливать и удалять (деинсталлировать).

Цель проекта Boson — это разработка встроенного движка базы данных документов JSON, написанный на C++. Основные возможности: стандартное хранилище JSON-документов в формате ключ/значениями с постоянным хранением на диске. Размер документов до 4Gb. Быстрый поиск документов по ID с использованием индекса B+ дерева. Поддержка курсоров для линейного обхода записей. База данных в одном файле, без временных файлов. Простое, чистое и легкое в использовании API. Самодостаточный и не требующий настройки.

В предыдущих двух статьях мы прошли шаги от кэширования файлового ввода/вода (часть I) до построенного на его базе хранилища записей произвольной длины (часть II) с проверкой целостности, возможностью получения записей списком и повторным использованием свободного места. Теперь мы переходим к завершающей части и "сердцу" СУБД - индексу.

Зачем нужен индекс: предположим, что в базе есть 1 млрд не отсортированных записей документов, тогда поиск конкретного документа по ID потребует O(n) операций, то есть до 1 млрд операций в худшем случае. Однако, если бы документы в базе были бы отсортированы по ID, то поиск в сортированной базе, тем же бинарным поиском занял бы O(log n) занял бы 30 операций. Что, теоретически, на базе в 1 млрд записей будет в 33.3 млн раз быстрее.

Фундаментальной (по моему мнению) проблемой множества языков программирования является неявное использование ссылок (ссылочных переменных).

И проблема не в том, что с помощью ссылок изменяются какие-то общие данные, а в том, что часто это делается неявным образом, из-за чего программист должен всегда помнить об особенностях таких переменных.

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

А как бы хотелось отдать эти проблемы на откуп компилятору! Чтобы компьютер сам автоматически проверял корректность доступа по ссылкам, в том числе и из разных потоков и чтобы все это делалось во время компиляции приложения без накладных расходов в рантайме!

И если такое будет возможно, тогда постепенно уйдет в прошлое целая эпоха сборщиков мусора с их неожиданными зависаниями программ в произвольные моменты времени и разными мудреными алгоритмами поиска мертвых указателей и циклических ссылок!

31 октября 2024 года, 11:00, автор: Дэррил К. Тафт

Это самая жёсткая позиция правительства в отношении безопасности программного обеспечения, которая предупреждает производителей: устраняйте опасные методы программирования, иначе вас могут обвинить в халатности.
Федеральное правительство предупреждает об опасных методах разработки программного обеспечения. Агентство по кибербезопасности и защите инфраструктуры США (CISA) и Федеральное бюро расследований (ФБР) публикуют жёсткие предупреждения о нарушениях базовых мер безопасности, которые продолжают затрагивать критически важную инфраструктуру.

В недавнем отчёте, опубликованном совместно CISA и ФБР, о недостаточных мерах обеспечения безопасности продуктов производители программного обеспечения предупреждаются о нежелательности использования небезопасных для памяти языков программирования, таких как C и C++.
«Разработка новых линеек продуктов для использования в критически важной инфраструктуре или [национальных критически важных функциях] NCF на языке, небезопасном для памяти (например, C или C++), когда есть доступные альтернативные языки, безопасные для памяти, которые можно использовать, несет в себе угрозу и значительно повышает риск для национальной безопасности, национальной экономической безопасности, здоровья и безопасности населения», — говорится в отчёте.