В наше время иррационализма, утечек данных с серверов, постоянного внедрения рекламы тут и там, мошенничества, неумелого программирования, приложения начинают не помогать, а раздражать, а то и вовсе могут нанести вред. Поэтому в купе с несправедливостью и желанием сделать всё самому, в этой статье, мне охота показать, как легко сделать одно из бытовых приложений своими руками, на примере приложения хранения паролей, с помощью текстового файла, шифрования и облака.
Эта статья посвящена разработке многопоточной базы данных. Мы рассмотрим основные компоненты, такие как хранилище данных, транзакционные системы, многопоточность, журналирование и восстановление, а также создание API для взаимодействия с базой данных. Примеры кода на языке 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.
