Для большинства случаев дебаггинга вам должно с головой хватать стандартных точек останова (breakpoints или брейкпоинтов). Но иногда кода для проверки, объектов или случаев попросту слишком много. Что делать, если мы хотим отфильтровать код, генерирующий точку останова? Прошу вас поприветствовать условные точки останова!
До C++17 у нас было несколько довольно неэлегантных способов написать static if (if, который работает во время компиляции). Например, мы можем использовать статическую диспетчеризацию или SFINAE. К счастью, ситуация изменилась к лучшему, ведь теперь мы можем воспользоваться для этого if constexpr и концептами C++20!
Ну что ж, давайте разберемся, как мы можем использовать это в качестве замены std::enable_if кода!
В этом посте я расскажу о некоторых уловках, которыми я воспользовалась, чтобы уменьшить двоичные файлы С/С++/Python с помощью ассемблера для x86. Здесь всё крутится вокруг кодовой базы Cosmopolitan. Дело в том, что из недавнего отзыва по проекту ELKS я узнала, что мой код там всем понравился и они хотят узнать больше о том, что трюки cosmo могут дать проектам вроде «Linux-порта i8086». Я почувствовала, что мы с ребятами проекта ELKS «одной крови», ведь первое, что я написала при создании Cosmopolitan, — это загрузчик i8086, который назывался Actually Portable Executable. А ещё мне было приятно узнать, что людям, которые погрузились в эту проблему гораздо раньше меня, нравятся мои наработки в Cosmopolitan. И тогда я решила, что неплохо было бы поделиться ими с более широкой аудиторией.
![[Shinmyoumaru Sukuna]](https://habrastorage.org/webt/fz/j8/2s/fzj82s9csxx81rj8iyj7ph38l3q.png)
Всем ведь приходилось заниматься улучшением производительности? Для игр особенно актуально, ну может какая-то три-в-ряд не страдает этим. Как обычно серебряной пули нет, начинаем со структур данных, алгоритмов, спускаемся ниже если не помогает, придумываем SoA, AoS шаблоны. Если проблема не решается, подтягиваем профайлеры и предметно разбираем узкие места, но все чтобы мы не делали зачастую таким узким местом всегда будет "железо". Можно сколько угодно оптимизировать другие места, но CPU c его гигагерцами будет простаивать 90% времени если его неправильно "кормить" данными. Одной (только одной из проблем) проблемой организации эффективной работы с данными будет меньше, если знать и уметь работать с кэшами разных уровней. Тут на вики описано, как "на пальцах" быстренько убить перф на обходе массива, простого и общего решения для такого обхода нет. Можно и дальше увеличивать размер кэша, что собственно и делают (гдето здесь на хабре была новость, что Интел при переходе на L1 кэш размером 32кб, заново спроектировал блок доступа к нему, сорян не нашел ссылку), но это дорого, неэффективно на масштабах современных процов, и всегда найдутся данные, которые этот кэш отравят, опять. Интересно как починить? го под кат...
На Хабре уже неоднократно появлялись статьи, посвященные применению современных стандартов C++ при программировании микроконтроллеров, в том числе и появившихся в c++20 корутин.
Предлагаю спуститься со сложных решений типа целой операционной системы и рассмотреть вопросы примитивного планирования задач с применением сопрограмм.
В первой статье рассказали, почему нам потребовалась автоматическая кодогенерация свифтового интерфейса для C++ в Mobile SDK. Описали инструменты, которые есть в нашем распоряжении, и сделали вывод: лучший промежуточный слой для преобразования на сегодняшний день — это C.
Во второй части рассказываем о собственном инструменте, который поддерживает и Swift, и Kotlin — мы называем его Codegen (да :)).
std::format — очень полезное (и серьезное) нововведение C++20, позволяющее нам форматировать текст в строки удобным и эффективным образом. Оно привносит в язык форматирование в стиле Python в сочетании с безопасностью и простотой использования.
В этой статье я расскажу, как реализовать пользовательские средства форматирования (форматтеры) в соответствии с новой std::format архитектурой.
Что такое WiFi-флешка? Это флешка, которая опознается, как флешка, пахнет, как флешка, крякает, как флешка, но на самом деле никакая она не флешка, она эмулирует файловую систему, а данные берет по WiFi с сервера.
Ранее в нашем блоге мы рассказывали о квизе для C++ разработчиков. С момента запуска мы тщательно собирали обратную связь. Часть из неё касалась ошибок в работе квиза, которые мы естественно решили исправить.
В стандартной библиотеке языка программирования C++ существует много классов, наделенных если не абсолютно одинаковыми свойствами, то очень похожими.
Так, стандарт вводит отдельное требование BitmaskType, описывающее свойства, какими должны обладать битовые маски в стандартной библиотеке: для них должен быть определены операции «и», «или», «не», а значение 0 должно представлять пустую маску.
В стандартной библиотеке классов, от которых требуется соблюдение этого требования, очень много: std::chars_format, std::launch, std::filesystem::perms, std::filesystem::perm_options, std::filesystem::copy_options, std::filesystem::directory_options... Единственное, чем они отличаются — это набором возможных значений. Реализации же битовых операций над ними похожи как две капли воды.
В данной статье мы поговорим о том, как такое средство как метаклассы в некоторых случаях способно спасти программиста от написания простынь бойлерплейта.
Привет, Хабр! Меня зовут Владимир, я работаю в VK Карты. Хочу рассказать про случай, который недавно произошёл у нас в подразделении. Он кажется достаточно типичным и может быть интересен другим программистам.
Нам, программистам на C++, не привыкать, что даже самый безобидный код может таить в себе сюрпризы. Рассмотрим пример:
uint32_t width = 7;
int32_t signed_offset = -width;
Он полон сюрпризов! Каких? Короткий ответ: значение signed_offset не определено стандартом и зависит от реализации. Но это далеко не все неожиданности в этом коде. Статья как раз о них.
Хочу рассказать о том, как занимался оптимизацией card raytracer - минимального рейтрейсера, код которого умещается на визитке.
Точнее, это развёрнутая для лучшей читабельности версия, которая в форумной ветке
использовалась как тест скорости разных языков.
Когда я наткнулся на эту ветку, я как раз изучал компиляторы Cи, и конечно немедленно вознамерился всех порвать обогнать. В результате действительно обогнал, но с нарушением правил - слегка поправив структуру данных.
Тем не менее, это хороший пример того, как можно "заточить" код под векторизацию, с сохранением читабельности и умеренным ростом объёма и сложности. Я расскажу, какие есть варианты векторизации, как перестроить код и данные, и наконец, как переложить на компилятор черновую работу по кодогенерации - используется автовекторизация, векторные расширения и совсем немного интринсики.
Наверное, статья в большей степени полезна новичкам, но и опытные разработчики (по привычке с 2000-го года пишущие SIMD-код интринсиками) могут найти что-то новое.
Компилятор - в основном Clang, можно GCC, в конечном итоге я адаптировал и под MSVC.
a = 5 — можно.5 = a — в общем-то, бессмысленно.a = b. Но, указывая куда ставить, нужно говорить именно о блюдце. И вообще, все чашки, которые вы не держите в руках, должны иметь соответствующее блюдце, потому что скатерть заколдована — на ней чашки без блюдца опрокидываются.
Привет, Хабр!
Перед вами продолжение статьи про рендеринг. В первой части, которую вы, кстати, можете найти по ссылке (link), мы поговорили о трассировке лучей и маршевом методе, а в этой части мы с вами получим фотографию мыльного пузыря. Будет интересно :)
C и C++ программисты в какой-то момент могут столкнуться с ограниченным размером PATH_MAX и задаться вопросом – какого размера создавать буфер, чтобы отследить путь к директориям или файлам?
Qt5.8 принёс нам QNetworkAuthorization -- модуль авторизации на сторонних сервисах. Пока что поддерживаются только протоколы OAuth и OAuth2.0, но обещали позже подвезти и OpenID.
А пока разберёмся, как использовать этот инструмент совместно с VkApi для Authorization Code Flow
Данное руководство позволит читателю составить полную картину того, как организовать сборку C++ библиотек с использованием современных возможностей CMake. Предполагается, что читатель имеет представление о базовых понятиях из мира CMake и динамических/статических C++ библиотек, так как в руководстве они могут не объясняться.
Генерация 3д объекта - как правило, многоэтапный процесс (например в булевых операциях сначала поиск графа пересечений, нахождение геометрии кривых пересечения и построение топологии результирующего тела). Закономерно возникает сложность с его отладкой. Положим при генерации что-то пошло не так и имеем наполовину готовый объект, который не может быть визуализирован разрабатываемой CAD системой. Что делать? Как локализовать место и момент ошибки? Анализировать глазами тысячи xyz координат промежуточных результатов и вспомогательных объектов на момент выдачи исключения? Или хуже, если отклонения желаемого результата от фактического незначительные, тогда и все числа внешне будут корректны. Работая С++ программистом в области 3Д моделирования и построения различных CAD/САПР систем, я регулярно сталкивался с проблемой визуализации вспомогательных/промежуточных сущностей.
Сформировал себе универсальный инструментарий DumpSTL, позволяющий с минимальными усилиями, в любом C++ проекте дампить в .stl файлы любые внутренние объекты в проекте.
Почему именно .stl? Так уж исторически сложилось. Много использовал чпу фрезера и 3д принтера, где основным и простейшим форматом моделей является .stl.
Суть использования сводится к однократной адаптации инструмента под структуры данных конкретного проекта, затем:
1) подключить один DumpSTL.h
2) вызвать к необходимым данным метод DUMP::save(...)
3) получить на выходе множество файлов с 3д моделями, которые можно открыть в любом 3д редакторе