Мы привыкли думать, что плохой код — это результат недостатка знаний, опыта или времени. Но что, если причина кроется глубже — в самой природе человеческого мышления? Многочисленные исследования в области когнитивной психологии показывают, что наш мозг подвержен систематическим ошибкам, которые влияют на все аспекты профессиональной деятельности, включая разработку программного обеспечения.

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

Если разработку под устройства можно сравнить с тёмным лесом, то как в нём не заплутать?

Привет, путник! Меня зовут Денис Малых, я работаю в Яндексе и руковожу разработкой общих компонент для платформы, на которой работают наши устройства. А ещё — я член программного комитета конференции AppsConf, где мы обсуждаем разработку под мобильные ОС. В этой статье поделюсь опытом разработки под нестандартные устройства: чем она принципиально отличается от привычной мобильной разработки, и что нужно уметь, чтобы разрабатывать «умные вещи».

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это восьмая статья из серии, список предыдущих статей приведен в разделе 6.

C++ относится к языкам со статической типизацией, то есть тип переменных определяется на стадии компиляции, но в ряде случаев компилятору для компиляции без ошибок достаточно знать, что то или иное имя является именем какого-то пользовательского типа (класса, структуры, объединения, перечисления), а полное объявление типа не нужно. В этом случае можно использовать неполное объявление (incomplete declaration), называемое еще упреждающим или предваряющим (forward declaration). Типы с неполным объявлением называются неполными.

Использование неполных объявлений позволяет решить ряд проблем, традиционно свойственных коду, написанному на С++. Отметим следующие:

1. Можно уменьшить количество включений заголовочных файлов в другие файлы проекта, что сокращает время компиляции, снижает замусоривание пространств имен неиспользуемыми именами, предупреждает потенциальные конфликты имен;
2. Можно реализовать решения, полностью разделяющие интерфейс и реализацию (непрозрачные указатели);
3. Можно разрывать циклические зависимости;
4. Можно снизить использование нетипизированных указателей void*, что повышает надежность и читаемость кода.

Грамотное использование неполных объявлений — один из признаков профессионального кода.

Справочники, или словари — обычно большие объёмы статических данных, адресуемые и не модифицируемые при работе программы. Как правило, подготавливаются или загодя, при разработке, или вне программы, или в специальных её режимах. Зачастую с ними обращаются как с обычными структурами, однако можно организовывать их и иначе — так, чтобы работа с ними шла вообще без резервирования памяти и каких‑либо лишних операций, а в памяти они занимали минимально возможный объём.

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

Знакомо? Добро пожаловать в увлекательный мир когнитивных искажений разработчика — ментальных ловушек, которые саботируют наши проекты, несмотря на годы опыта и техническую экспертизу.

Наш мозг — не идеальная машина для написания кода. Миллионы лет эволюции создали его для выживания в саванне, а не для проектирования микросервисных архитектур или оценки спринтов. Когнитивные искажения — это сбои в нашем мышлении, систематические ошибки, которые влияют на каждое решение, от оценки времени на задачу до выбора архитектуры приложения.

В этой статье мы создадим интерактивную визуализацию алгоритма быстрой сортировки (QuickSort) с использованием библиотеки SFML и современных возможностей C++20. Этот проект поможет вам лучше понять, как работает один из самых популярных алгоритмов сортировки, и покажет, как можно комбинировать графику и алгоритмы для создания образовательных инструментов.

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

Я не являюсь специалистом по Rust, но после просьбы помочь разобраться этим вопросом, был переадресован искать эту очевидную информацию самостоятельно, так как "джентльменам верят на слово". Тогда как косвенным подтверждением моего предположения об отсутствии формального доказательства в общем виде, является тот факт, что отсутствует и полный список разрешающих и/или запрещающих проверок, которые реализованы в самом компиляторе языка.

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

Когда я сам переучивался на разработчика, я быстро понял: можно годами смотреть курсы, читать книги и учиться на собственных ошибках — а можно взять ментора и пройти этот путь в разы быстрее. Менторинг — это то, что помогает не просто получать знания, а применять их в реальной работе. 

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

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

Хотя инструментов для сериализации существует достаточно много, я предлагаю вашему вниманию ещё один. Он не лучше и не хуже других, и был создан с акцентом на простоту (кто бы мог подумать?) и компактность (опять же!), не сильно влияющую на производительность работы с ранее сериализованными данными.

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

В этой статье рассмотрим то, как создаются нативные аддоны для Node.js на C++ с использованием N-API.

До появленияN‑API написание аддонов шло напрямую через V8 API, что влекло за собой жёсткую привязку к конкретной версии движка. Каждый апдейт Node.js требовал пересборки и правки кучи низкоуровневого кода. N‑API решает эту проблему, предоставляя стабильный ABI. Это позволяет писать универсальные, долговечные и, главное, поддерживаемые модули, не боясь, что обновление Node.js подбросит вам сюрприз в виде «segmentation fault».

Мне недавно встретился код вывода количества FPS на экран, написанный начинающим программистом, и в этом коде был базовый класс, класс-потомок, виртуальные функции, конструктор с множеством параметров, variant. Код позволял выводить любое количество счетчиков FPS на экран разными шрифтами, но все, что было на самом деле нужно, это простая функция на 3 строки, считающая количество FPS и выводящая его на экран.

Давайте натрём наши болиды до блеска и посмотрим, как они входят в повороты компиляторных оптимизаций на примере использования std::array. Смогут ли они не только не уступить, но и обогнать встроенный массив?

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

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

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить канонические ошибки и опечатки. Многих из них можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте посмотрим на эти ошибки и подумаем, как можно повести рефакторинг кода так, чтобы им просто не было там места.

С3D Solver – это инструмент для разработчиков, работающих с 2D и 3D-моделированием. Он позволяет создавать параметрические сборки из твёрдых тел и эскизы, накладывая на них связи (ограничения). Мы остановимся непосредственно на трёхмерном решателе, чтобы на его примере ответить на возникающие у разработчиков приложений вопросы, которые и послужили толчком к написанию данной статьи. Например, расскажем о значении синхронизации представлений геометрических объектов – это наиболее распространенная проблема, возникающая при использовании трёхмерного решателя. А также в рамках статьи погрузимся в основные аспекты работы программиста конечного приложения с С3D Solver, рассмотрим функциональность математической библиотеки и пройдём путь от клика по иконке до сопряжения геометрических объектов на конкретном примере.

Чтобы лучше ориентироваться в предметной области и терминах, которые будут упоминаться, начнём с краткого описания базовых понятий. В статье рассмотрим три представления твёрдых тел. Изображение модели, которую пользователь видит на экране, мы будем называть графическим представлением. Следующее представление – модельное. Оно включает в себя описание топологии моделируемого объекта, связей элементов геометрической модели, историю её построения и атрибуты элементов. За него отвечает геометрическое ядро C3D Modeler. Наконец, есть параметрическое представление, которое обеспечивает взаимосвязь элементов модели, позволяя редактировать её, синхронно изменяя положение тел. Воплощается оно в системе геометрических ограничений GCM_System под управлением C3D Solver, который не имеет прямой связи с твёрдыми телами модельного представления. Отсюда возникает важная особенность – необходимость синхронизации представлений.

Совсем недавно моя машина была в таком запущенном состоянии, что я едва мог подключиться к ней через ssh. 3200% нагрузки на CPU — полностью использовались все 32 ядра хоста! Сравните это с моим последним багом, когда использовалось всего одно ядро, то есть 100%

К счастью, я использовал среду выполнения Java 17, у которой были дампы потоков с указанием времени CPU!

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

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

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

В данной статье рассматривается использование механизма разделяемой памяти (shared memory) для эффективной передачи данных между независимыми процессами в рамках одной машины. Цель статьи — продемонстрировать не только базовые принципы работы с разделяемой памятью, но и показать, как размещать в ней высокоуровневые контейнеры, такие как хеш-таблицы (unordered_map), а также рассмотреть практический пример потоковой обработки данных при помощи кольцевого буфера.

С релизом PVS-Studio 7.35 в анализаторе появилось много новых диагностических правил. Вас ждёт: много MISRA для C, новые Unity-диагностики для C# и покрытие OWASP Top 10 для Java и многое другое!
Подробности вы сможете узнать в этой заметке.

В октябре 2024 года я описал историю создания программатора микросхем CH341a для Linux систем. Год назад я рассказал о дополнительных возможностях программы, появившихся позднее. Давайте посмотрим, что изменилось в программе за год.