У C и C++ программистов две головные боли в плане ошибок: утечки памяти и неопределённое поведение. И как вы догадались из названия, речь пойдёт о неопределённом поведении. И каком‑то «моём» компиляторе. Если точнее, то о наборе компиляторов и инструментах для их разработки, а именно LLVM. Почему «моём»? Потому что мы очень любим Clang, входящий в состав LLVM, и пользуемся им на постоянной основе.
Статические анализаторы помогают не только обнаруживать ошибки и дефекты безопасности, но и делать код чище. Выявляя лишние проверки, дублирующие действия и другие аномалии, можно сделать код проще, красивее и легче для чтения. Разберём это на практическом примере рефакторинга функции.
Всем привет! Изучив несколько статей по этой теме, у меня остались вопросы, и некоторые моменты по-прежнему были не понятны, поэтому я решил написать свою, которая, как мне кажется, была бы понятна тем, кто не силен в спортивном программировании. В ней я объясняю, как устроено дерево отрезков. Примеры с кодом будут приведены на языке C++, однако на объяснение это не влияет.
Доброго всем дня!
Хочу рассказать о своём практическом опыте реализации взаимодействия между процессами в среде Linux в условиях, когда вычислительных ресурсов существенно не хватает. По условию, один из процессов написан на C++, второй на PHP, потому дополнительно мы рассмотрим доступность соответствующих API из PHP а также варианты действий в случае, когда для нужного API PHP-обёртка отсутствует.
Тема безопасного и эргономичного взаимодействия между Rust и C/C++ была популярна на конференции RustConf 2025, состоявшейся в Сиэтле, штат Вашингтон. Чендлер Каррут выступил с презентацией, в которой представил различные способы взаимодействия между Rust и Carbon — экспериментальным языком, который можно условно обозначить как «(C++)++». Он резюмировал, что, пусть возможности стыковки Rust с другими языками со временем расширяются, в обозримом будущем не стоит ожидать, что будет полноценно решена проблема его взаимодействия с C++. Поэтому как раз появляется ниша для Carbon, который может предложить иной подход для постепенного совершенствования существующих проектов на C++. Вот слайды к его презентации — для тех, кто хотел бы изучить код его примеров более подробно.
Новый стандарт C++, C++23, впервые с C++11 расширил всем привычную линейку контейнеров: помимо знакомых array, vector, (unordered_)set, (unordered_)map и прочим в нее теперь входят непонятные flat_set, flat_map, flat_multiset и flat_multimap. Ответим на вопросы, что это за контейнеры, когда они могут быть полезны, сравним дизайн стандартизированных «плоских» контейнеров с дизайном плоских контейнеров из Boost и ETL и, конечно, произведём замеры и сравним производительность flat_ и не flat_ контейнеров.
Привет, Хабр! Меня зовут Алексей Салтыков, я инженер-программист в команде КОМПАС-3D. Решил поделиться соображениями насчет оптимизаций в С++ глазами обычного разработчика. Хочется сразу предупредить, что статья никого ни к чему не призывает. Цель – наглядно показать, как незначительные трансформации кода могут помочь компилятору лучше оптимизировать код и насколько это вообще эффективно.
Так или иначе сталкиваться с регулярными выражениями приходилось большинству разработчиков. Мое первое знакомство произошло с реализацией regex в STL std::regexp. Чаще всего регулярки используются в проверке входных данных, что-то вроде проверки корректности введенного пользователем URL, адреса IPv4, адреса IPv6, телефонного номера и при этом скорость выполнения операции regex не сильно влияет на время отклика от приложения. Но, что если вам приходится проверять сотни, тысячи или даже десятки тысяч правил и все это на постоянно меняющихся наборах входных данных в реальном времени? В этой ситуации вам не просто нужен быстрый алгоритм, вам понадобится лучший из них, вам понадобиться чемпион!
Как и обещал в предыдущей статье, пишу о нашем опыте работы с контактными ключами Metacom и Cyfral.
Эти ключи построены на микросхемах 1233KT1 и 1233KT2, которые не сильно друг от друга отличаются и имеют очень схожий принцип работы.
При подаче питания ключ просто выдает свой id. При этом никакие команды ключ не принимает и не посылает, а проверка правильности считывания ключа производится путем повторного считывания. Первым, для определения начала передачи, всегда идет стартовое слово. В отличие от ключей Dallas, они работают не по напряжению, а по току. Это менее распространенные и более дорогие ключи. Таким образом, логические уровни определяются сопротивлением ключа (около 400 Ом и 800 Ом). А значение бита определяется длительностью удержания низкого и высокого значения потребления тока.
Разберем эти ключи по отдельности...
Год назад я написал статью об отладке STM32 микроконтроллеров из под VSCode, с компиляцией в GCC и сборкой с помощью CMake. А в декабре мне в руки попали две тестовые единицы отечественных микроконтроллеров К1986ВЕ92FI (MDR1211FI1). Производитель имеет свою библиотеку SPL на C, а также неплохую базу примеров инициализации и применения различной периферии в Keil и IAR; однако я, average C++20+ enjoyer , решил попробовать перенести свой тулчейн на новое железо.
После некоторых поисков серьёзного вызова для анализатора PVS-Studio выбор пал на открытую коллекцию компиляторов GCC. Да, это уже не первая по счёту проверка этого проекта. Однако поддерживаемые этой коллекцией языки программирования не стоят на месте, и их постоянное развитие влечёт за собой соответствующее постоянное усложнение кода GCC. Таким образом цель — обнаружить ошибки в коде GCC с помощью анализатора PVS-Studio.
Код некоторых модулей Erlang/OTP старше, чем большинство современных junior-разработчиков. Эти файлы — настоящие цифровые патриархи, десятилетиями обеспечивающие работу банковских транзакций, телефонных сетей и систем обмена сообщениями. Мы решили заглянуть под "капот" этого языка-долгожителя, чтобы проверить, что именно скрывается в строках, на которые сегодня полагаются миллионы пользователей. А вот что мы нашли, узнаем в этой статье.
Всем привет!
Пишу этот пост, чтобы поделиться своим опытом и получить критику или советы от людей с большим опытом.
Мне 22 года, я из Латвии. По образованию я судовой механик, но уже около 4 лет увлекаюсь программированием. Долгое время это оставалось хобби: пробовал сайты, простые игры — но они не приносили настоящего удовольствия. Я считал, что в программировании нужно было разбираться ещё со школы, и долго не верил, что могу найти себя в этой сфере.
Переломный момент наступил, когда я заинтересовался системным программированием. Каждый раз, когда узнаю, как работает низкоуровневая часть ОС, у меня будто открывается новый мир. Особенно зацепила тема процессорного планирования: все говорят «железо, CPU, видеокарта», но на практике даже реализация планировщика процессов может заметно влиять на производительность.
Привет Хабр! В этой статье я хотел поговорить о теме вечных конфликтов разработчиков на C++ и Rust. Стоит ли того система управления памятью в Rust или все-же это бестолковый механизм стремящийся составить конкуренцию родному методу?
Систему управления памятью я разберу, а вот выводы остаются уже за вами.
На прошлой неделе в Софии, столице Болгарии, закончилась работа над стандартом C++26, который помимо контрактов, std::execution и всего прочего теперь включает и рефлексию.
В этой статье будет продемонстрирован один из примеров её использования: преобразование строк в формате JSON в объекты C++ на этапе компиляции.
Привет, Хабр! Продолжим разговор про свертки в ML-обучении на C++. Мы уже обсудили, какие есть подходы к реализации сверток, — ссылку на первую часть ищите в конце статьи.
Теперь поговорим, как в одном моем проекте нужно было расширить функциональность PyTorch для работы со свертками размерностью больше трех, а потом использовать их в обучении моделей. Сначала рассмотрим, какие ограничения на выбор алгоритма накладывает возможность обучения моделей, а затем изучим два подхода к реализации свертки и адаптируем их к нашей задаче.
Вы когда-нибудь мечтали о динамически расширяемом последовательном контейнере с фиксированной емкостью, хранящем свои элементы на стеке? Комитет по стандартизации C++ исполняет желания! Теперь вам не нужно обращаться к Boost.Container за boost::container::static_vector. Встречайте, std::inplace_vector (P0843), принятый в C++26!
На конференции FPGA-Systems был предоставлен маршрут проектирования блоков микросхем на основе использования C++ под названием ИРИС. Докладчик - заведующий кафедрой Мехмата МГУ Эльяр Гасанов. Его группа имеет значительный опыт проектирования оптимизированных по производительности блоков, например LDPC декодера, и ведет свои истоки из сотрудничества с LSI Logic в середине 1990-х годов.
Мои мысли после просмотра презентации:
