C++ *

Здесь будет длиннющая стена текста, с типа случайными мыслями. Основные идеи:

1. В C++ очень важно время компиляции,
2. Производительность сборки без оптимизаций тоже важна,
3. Когнитивная нагрузка ещё важней. Вот по этому пункту особо распространяться не буду, но если язык программирования заставляет меня чувствовать себя тупым, вряд ли я его буду использовать или тем более — любить. C++ делает это со мной постоянно.

Блогпост «Standard Ranges» Эрика Ниблера, посвященный ренжам в C++20, недавно облетел всю твиттерную вселенную, сопровождаясь кучей не очень лестных комментариев (это ещё мягко сказано!) о состоянии современного C++.

Даже я внёс свою лепту (ссылка):

Этот пример пифагоровых троек на ренжах C++20, по моему, выглядит чудовищно. И да, я понимаю, что ренжи могут быть полезны, проекции могут быть полезны и так далее. Тем не менее, пример жуткий. Зачем кому-то может понадобиться такое?

Давайте подробно разберём всё это под катом.

Некоторое время назад ссылка на статью "Modern dining philosophers" распространилась по ресурсам вроде Reddit и HackerNews. Статья интересная, она показывает несколько решений этой известной задачи, реализованных на современном C++ с использованием task-based подхода. Если кто-то это статью еще не читал, то имеет смысл потратить время и прочесть ее.

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

При этом task-based подход не является единственным возможным для решения подобных задач. Почему бы не посмотреть, как задача "обедающих философов" решается посредством моделей Акторов и CSP?

Посему попробовал посмотреть и реализовал несколько решений этой задачи как с использованием Акторов, так и с использованием CSP. Код этих решений можно найти в репозитории на GitHub-е. А под катом пояснения и объяснения, так что кому интересно, милости прошу под кат.

Всем привет!

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

Все шаги проверены на виртуальной машине со свежеустановленной Ubuntu 16.04 xenial desktop x64.

Подразумевается, что у Вас уже есть исходники какого-либо проекта.

Все настройки, касающиеся конкретного железа (в моём случае это контроллер STM32F429 и девборда STM32F429DISCO), нужно подменить на свои. То же самое касается и путей.

Если готовы, то

*Ссылка на библиотеку и демо видео в конце статьи. Для понимания того, что происходит, и кто все эти люди, рекомендую прочитать предыдущую статью.

В прошлой статье мы ознакомились с подходом, позволяющим осуществлять "горячую" перезагрузку c++ кода. "Код" в данном случае — это функции, данные и их согласованная работа друг с другом. С функциями особых проблем нет, перенаправляем поток выполнения из старой функции в новую, и все работает. Проблема возникает с данными (статическими и глобальными переменными), а именно со стратегией их синхронизации в старом и новом коде. В первой реализации эта стратегия была очень топорной: просто копируем значения всех статических переменных из старого кода в новый, чтобы новый код, ссылаясь на новые переменные, работал со значениями из старого кода. Конечно это некорректно, и сегодня мы попытаемся исправить этот изъян, попутно решив ряд небольших, но интересных задач.

В статье опущены детали, касающиеся механической работы, например чтение символов и релокаций из elf и mach-o файлов. Упор делается на тонких моментах, с которыми я столкнулся в процессе реализации, и которые могут быть полезны кому-то, кто, как и я недавно, ищет ответы.

Что может быть хуже костылей? Только неполно документированные костыли.

Перед вами скриншот из последней официальной интегрированной среды разработки для 8-битных микроконтроллеров AVR, Atmel Studio 7, язык программирования Си. Как видно из столбца Value, переменная my_array содержит число 0x8089. Другими словами, массив my_array располагается в памяти, начиная с адреса 0x8089.

В то же время столбец Type даёт нам несколько иную информацию: my_array является массивом из 4 элементов типа int16_t, расположенным в ПЗУ (это обозначается словом prog, в отличие от data для ОЗУ), начиная с адреса 0x18089. Стоп, но ведь 0x8089 != 0x18089. Какой же на самом деле адрес у массива?

Всем привет! Представьте, что C++ Russia больше нет. Куда вы пойдёте вместо этого? Есть множество конференций, посвящённых более широким темам, но наша — одна из немногих, целиком и полностью сфокусированная на C++ и открыто заявляющая, что это будет реальный хардкор. Выбора немного. Хорошо, что мы никуда не исчезали! В следующий раз C++ Russia пройдёт уже этой весной.

Конференция состоится 19-20 апреля в Москве. Скорее всего, будет дополнительный третий день мастер-классов, которые не входят в основную программу.

Темы докладов: многопоточность и параллельные вычисления, новые фичи языка и компиляторов, сборка и инфраструктура сложных проектов с большими кодовыми базами, производительность и низкоуровневая жесть, метапрограммирование, функциональное программирование и другие парадигмы, архитектура сложных проектов, и многое другое.

Если спросить C++-программиста о значении ключевого слова explicit, большинство ответит, что это ключевое слово ставится перед объявлением конструктора с одним параметром (или с большим числом параметров, но когда все параметры, начиная со второго, имеют значения по умолчанию) и предотвращает неявное преобразование типов при инициализации.

• контейнер (container): управляет набором объектов в памяти.
• итератор (iterator): обеспечивает для алгоритма средство доступа к содержимому контейнера.
• алгоритм (algorithm): определяет вычислительную процедуру.
• функциональный объект (function object): инкапсулирует функцию в объекте для использования другими компонентами.
• адаптер (adaptor): адаптирует компонент для обеспечения различного интерфейса.