C++ *

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

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

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

Итак, создав ранее тест потоков (о нем подробнее см. [1]), гоняя его многократно и в разных режимах, я заметил, что пусть редко, но выскакивают некорректные результаты. В подобных случаях я грешу обычно на себя. А в данном случае тем более, т.к., что там скрывать, имею весьма небольшой опыт использования потоков.

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

У C и C++ программистов две головные боли в плане ошибок: утечки памяти и неопределённое поведение. И как вы догадались из названия, речь пойдёт о неопределённом поведении. И каком‑то «моём» компиляторе. Если точнее, то о наборе компиляторов и инструментах для их разработки, а именно LLVM. Почему «моём»? Потому что мы очень любим Clang, входящий в состав LLVM, и пользуемся им на постоянной основе.

Обсуждение недавно опубликованной статьи натолкнуло меня на мысль написать свою программу, генерирующую последовательности изображений с анимацией фракталов. Прилагается программа с исходным кодом, примеры изображений и видео, полученное из последовательности изображений.

Все мы любим делать вещи правильно. В интернете можно найти много статей с названием вроде «10 антипаттернов <...>», и, когда я пришёл на свою первую работу разработчиком, я думал, что из этих статей понял, как делать правильно, а как нет. К сожалению, реальность не всегда делится на плохое и хорошее, и некоторые вещи, которые встречаются в подобных статьях, всё-таки могут принести большую пользу при разработке.

На конференции FPGA-Systems был предоставлен маршрут проектирования блоков микросхем на основе использования C++ под названием ИРИС. Докладчик - заведующий кафедрой Мехмата МГУ Эльяр Гасанов. Его группа имеет значительный опыт проектирования оптимизированных по производительности блоков, например LDPC декодера, и ведет свои истоки из сотрудничества с LSI Logic в середине 1990-х годов.

Мои мысли после просмотра презентации:

Привет, Хабр!

Задумывались ли вы когда-нибудь, что вашему коду стоило бы пройти сеанс психотерапии? В C++ это возможно благодаря такой замечательной штуке, как рефлексия. Она позволяет вашему коду буквально видить в зеркале себя и понимать свои ошибки и достоинства.

Итак, рефлексия — это процесс, при котором программа может инспектировать и изменять структуру и поведение во время выполнения.

Рефлексия в C++ бывает двух основных типов: компиляционная и рефлексия времени выполнения. Оба типа имеют свои особенности и применяются в различных сценариях.

Какую реальную точность можно ожидать от функции возвращающей время, а сколько времени она выполняется сама? Попытка замерить и сравнить несколько десятков функций, доступных программисту на C++.

Disclaimer. Данная работа не повлияла на мои взгляды на программирование, но повлекла достаточно радикальные изменения в подходах к проектированию автоматных объектов.  Теперь, если процесс  автономен и/или не предъявляет требований  к синхронизации, он может использовать другие механизмы параллелизма, не переставая при этом быть автоматным по сути. А почему так случилось, что этому предшествовало  и что это за изменения, вы прочтете далее.

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

По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку?

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Я ненавижу C++. Обычно мне нравится программировать, но каждый проект на C++, за который я брался, казался мне утомительной рутиной. В январе 2023 года я решил изучить Rust, чтобы иметь возможность сказать, что знаю язык системного программирования, который мне действительно хотелось бы использовать.

Первая стабильная версия Rust вышла в 2015 году, и с тех пор, начиная с 2016 года, он ежегодно признается самым любимым языком в ежегодном опросе разработчиков на Stack Overflow (теперь, в 2023 году, это называется "Востребованный"). Почему же разработчики, попробовав Rust, не могут перестать его использовать? В мире разрекламированных преемников C/C++ Rust, похоже, выходит на первое место. Как получилось, что язык, который появился на основной сцене всего в прошлом десятилетии, стал таким популярным?

Если спросить программиста, какие баги чаще всего можно встретить в C и C++ коде, он назовёт разыменование нулевого указателя, неопределённое поведение, выход за границу массива и другие, на его взгляд, типовые паттерны ошибок. Скорее всего, он назовёт и случайное присваивание в условии. Но действительно ли эта ошибка распространена в наше время?

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

LLVM — open-source проект с огромной кодовой базой. Лучший из лучших, если говорить о качестве кода, учитывая его размеры и открытость. Ведь кому, как не разработчикам инструментов для компиляторов, лучше знать о возможностях языка и правильном их использовании. Их код всегда на высоте, а найти ошибки в нём всегда вызов для нашего анализатора, который мы принимаем.

Решал алгоритмическую задачу. Написал код со сложностью O(n), работает правильно, но Leetcode посчитал, что это слишком долго. Посмотрел в решения, там тоже O(n), но код принимается, почему так?

Как-то раз Бобу поручили построчно обработать текстовый файл. Боб решил решить эту задачу на C++, так как известно, что мало найдётся языков, которые могли бы потягаться с C++ в скорости. Поскольку C++ для Боба — дело новое, неосвоенное, он решил погуглить спросить ChatGPT, какой способ построчного считывания файла на C++. Для этого потребовалось немного затравочного кода, зато не пришлось пролистывать бесконечные страницы документации по стандартной библиотеке C++.

Боб — джун с большими амбициями. Он всерьёз относится к своему ремеслу и репутации, поэтому ему важно убедиться, что код у него получается аппетитным — быстрым, элегантным и лучшим в своём роде.

💡

После этого Боб выложил окончательную версию кода на GitHub в файле TextFileReader.h, и вы смело можете использовать его в ваших проектах.

В этой статье мы рассмотрим, как правильно разрушать объекты в ООП программе на языке C++, не выполняя избыточных операций. Этим мы завершим цикл публикаций, посвящённый обзору ошибок в игровом движке qdEngine.

Я люблю С++. Это мой основной язык разработки на работе и в домашнем проекте. Я люблю его за скорость, за гибкость и близость к железу. Используя его, я понимаю "что происходит внутри". Я учился на нем программировать, и когда я пишу программы я "думаю на С++".

Я работаю в геймдеве, где С++ все еще популярен и ценится за все эти качества. Так же я много работал с C#, Lua, Python, немного JS и PHP. В общем, есть с чем сравнить.

Однако, у меня есть изрядная доля ненависти к С++. Я вижу в нем кучу проблем, которые не решаются годами. Я вижу как другие страдают от этих проблем.

В этой статье я хочу излить душу, за что я ненавижу С++. Мне от этого станет легче, возможно кому-то еще. Не стесняйтесь писать свой хейт (или защиту), устроим групповой сеанс терапии (или холивар)

Дисклеймер: Не стоит относиться слишком серьезно к этому тексту. Он наполнен душевной болью, и направлен лишь на релаксацию и сброс напряжения

Недавно Александр Муньис опубликовал новую математическую игру, которую назвал «Переверни список целых чисел». Заключается она в следующем.

- Составьте список разных положительных чисел (например, 10 5 3). Ваша цель — перевернуть список, используя «ходы» двух видов:

- Разделите одно из чисел на две части, которые в сумме дают целое; например, (10 5 4) может стать (7 3 5 4) или (10 2 3 4).

- Объедините два соседних числа в их сумму; например, (7 3 5 4) может стать (7 8 4) или (7 3 9).

Нельзя образовывать число, которое больше максимального числа в исходном списке. Например, если мы пытаемся изменить (10 5 4), то (7 5 3 4) может стать (7 8 4), но не может стать (12 3 4), так как 12 больше, чем 10 — максимальное число исходного списка. Также все элементы списка должны оставаться различными; например, (7 5 3 4) не может стать ни (7 5 7), ни (7 2 3 3 4).

Александр спрашивает: какие эффективные алгоритмы или общие стратегии существуют для решения этих задач? Для данного n должен быть некий список, где n — самое большое число, а количество ходов, необходимых для решения головоломки, является максимальным. Как выглядит последовательность максимально необходимого количества ходов в зависимости от n? Как выглядят самые «сложные» головоломки? Есть ли способ определить это без брутфорса?

В данной статье я рассмотрю подключение утилиты dfu‑util, написанную на языке С, к С++ проекту на CMake в виде сабмодуля.

Одна из главных целей статьи — это подключение старого и типового кода на С к своему проекту. Здесь приведены проблемы генерируемых файлов, борьба с кодом незнакомого разработчика (особенно если это разработчик на Си), особенности портирования окружения на Windows и т. д.

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

* Превью сгенерировано с помощью Adobe Firefly