C++ *

В предыдущей статье было показано, что при решении СЛАУ с симметричной разреженной матрицей наличие лидирующих нулей приводит к уменьшению количества вычислений. В этой статье будет представлен алгоритм, предназначенный для увеличения количества лидирующих нулей данной матрицы. Если переставить 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++), когда есть доступные альтернативные языки, безопасные для памяти, которые можно использовать, несет в себе угрозу и значительно повышает риск для национальной безопасности, национальной экономической безопасности, здоровья и безопасности населения», — говорится в отчёте.

В конце технического интервью, если кандидат ответил на вопросы и справился с задачами, у нас есть время для свободных вопросов, которые можно задать команде или кому-то из интервьюеров. Эту практику я переносил из компании в компанию, и она всегда помогала разрядить обстановку или вывести человека на разговор, если он был напряжен во время общения. Вопросы могут быть любые, кроме личных или тех, что под NDA. Обычно кандидаты задают технические вопросы по стеку, пайплайнам, иногда пытаются задать каверзные вопросы, особенно по плюсам, чтобы проверить нас. Иногда мы не можем ответить на них. Вопросы в стиле Google — например, «почему таблетки круглые?» — тоже встречаются, но недавно на одном из интервью прозвучал вопрос, на который вроде все и знали ответ, но никто сразу не смог его дать. Вопрос звучал так: «Какие общие технологии и решения появились в процессорах с времён 486, которыми мы часто пользуемся?»

Вопрос действительно интересный — что нового появилось, чем мы пользуемся каждый день? Что умеют современные процессоры, чего не могли процессоры год или два назад, пять или десять лет назад, сорок лет назад? Мы просто используем миллиарды транзисторов, даже не зная, как они работают. Покопавшись в Википедии, на сайте Агнера Фога и в документации Intel, я составил список того, что появилось и используется в современных процессорах. Всё, что указано ниже, относится в основном к x86 и консолям, если не указано иное. Поскольку консоли после третьего поколения PlayStation — фактически ПК с минимальными отличиями, речь дальше пойдёт в основном о ПК. История имеет склонность повторяться, и многое из того, что мы сейчас имеем, вводилось не один раз, просто под разными названиями.

Волновой алгоритм — это алгоритм поиска пути, который использует волновое распространение для определения кратчайшего пути от начальной вершины до целевой вершины.

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

14 ноября подключайтесь к онлайн-встрече разработчиков на C++. Инженеры из YADRO объяснят, как сочетать современное программирование с объектным подходом, расскажут об уникальных особенностях интрузивных контейнеров и познакомят с библиотекой Boost.Intrusive. После докладов эксперты из YADRO, Яндекса, Syntacore и Касперского обсудят удовлетворенность реализацией и внедрением фич в текущие стандарты C++.

Антон Полухин и Константин Владимиров — на одной площадке, когда еще такое случится! Регистрируйтесь, чтобы получить ссылку на трансляцию.

Привет, Хабр! Меня зовут Кирилл Колодяжный, я разрабатываю системы хранения данных в YADRO и изучаю нестандартные подходы к машинному обучению: создаю ML-проекты на С++. 

Это вторая часть цикла о разработке приложения для обнаружения предметов на С++. В прошлом материале мы выяснили, как создать проект в IDE Android Studio, реализовать сессию непрерывного захвата и преобразовать изображение в матрицу OpenCV. Ссылку вы найдете в конце статьи.

В этой статье продолжим реализацию проекта и обсудим следующие шаги:

• Как подключить к проекту библиотеки машинного обучения PyTorch и NCNN.

• Как получить модели YOLOv5 и YOLOv4 для использования на мобильном устройстве.

• Как реализовать инференс моделей для обнаружения объектов.

• Как обработать результаты работы моделей YOLO, реализовав алгоритмы Non-Maximum-Suppression и Intersection-Over-Union.

В конце сравним производительность PyTorch и NCNN и решим, какой фреймворк подойдет для задачи лучше.