Или как мы писали клиентскую C++ библиотеку для ZooKeeper, etcd и Consul KV

Добрый день уважаемые. Хотелось бы поделиться своей историей и маленьким лайфхаком.

Думаю у всех офисных работников бывает ситуация, когда после вкусненького обеда сильно разморило и хочется вздремнуть. На самом деле, дневной сон очень полезен как для организма, так и для работы, так как очень положительно влияет на продуктивность. Однако по моему опыту, более 20 минут — явный перебор. Этого достаточно чтобы организм привел себя в норму. И спустя буквально минуту, в течение которой очень хочется продолжить спать, организм просыпается, чувствуется бодрость и прилив сил.

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

Вступление

Это вторая часть истории о портировании шаблонного движка Jinja2 на C++. Первую можно почитать здесь: Шаблоны третьего порядка, или как я портировал Jinja2 на C++. В ней речь пойдёт о процессе рендеринга шаблонов. Или, иначе говоря, о написании "с нуля" интерпретатора питоноподобного языка.

В прошлой статье про написание конечных автоматов я обещал упаковать наш гениальный код в виде класса на C++ для повторного удобного использования. Делать буду так же на примере своей старой разработки SmartButton. Итак, влезаем в непонятный мир ардуининых библиотек и ООП.

Предлагаю вашему вниманию перевод статьи Super expressive code by Raising Levels of Abstraction

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

Проблема

Ниже будет представлен проблемный код. Мы преобразим этот невыразительный и непонятный код в ясный и элегантный.

Всем привет! В статье будет представлена упрощенная реализацию Stream из Java 8 на С++. Скажу сразу, что:

• в отличии от Java не используются отложенные вычисления;
• нет параллельных версий;
• местами совмещает Stream и Collectors;
• используются простые и готовые решения от STL, здесь нету чистого ФП, где только рекурсия;
• не используются техники оптимизации.

В этой версии основной упор сделан на то, чтобы быстро и просто сделать велосипед). Про ФП упомянуто по-минимуму (комбинаторам внимание не уделено :)).

Интерфейс

template <typename Type>
class Stream : private StreamImpl<Type>
{
private:
    typedef StreamImpl<Type> Parent;
public:
    using Parent::Parent; // конструкторы унаследованы
    using Parent::data;
    using Parent::isEmpty;
    using Parent::count;
    using Parent::flatMap;
    using Parent::map;
    using Parent::reduce;
    using Parent::filter;
    using Parent::allMatch;
    using Parent::noneMatch;
    using Parent::groupingBy;
    using Parent::partitionBy;
    using Parent::minElement;
    using Parent::maxElement;
    ~Stream() = default;
};

Всем привет! Ко мне через личку обратились товарищи, сказав что, они не хотят комментировать, то что не поняли или поняли не до конца и попросили дать пояснения. На основе присланных вопросов я попытаюсь дать ответы в доступной форме.

Чем полезны иммутабельные данные в С++?

Введение

Издавна графические ускорители (ГПУ) были созданы для обработки изображения и видео. В какой то момент ГПУ стали использоваться для вычислений общего назначения. Но развитие центральных процессоров тоже не стояло на месте: компания Intel ведет активные разработки в сторону развития векторных расширений (AVX256, AVX512, AVX1024). В итоге, появляются разные процессоры — Core, Xeon, Xeon Phi. Обработку изображений можно отнести к такому классу алгоритмов, которые легко векторизуются.
Но как показывает практика, несмотря на довольно высокий уровень компиляторов и технологичность центральных процессоров и сопроцессоров Xeon Phi, сделать обработку изображения с использованием векторных инструкций не так просто, так как современные компиляторы плохо справляются с автоматической векторизацией, а использовать векторные intrinsic функции достаточно трудоемко. Также возникает вопрос о совмещении векторизованного вручную кода и скалярных участков.

Обычно для подготовки отчета по профилированию на Linux я использовал только самые простые варианты запуска perf report (сами данные по производительности должны быть получены до запуска perf report командой perf record, вот тут можно подробнее прочесть с примером):

Отчет по модулям:

$ perf report --stdio --kallsyms=/boot/System.map-$(uname -r) --sort=dso -g none

Отчет по функциям:

perf report -g none --stdio --kallsyms=/boot/System.map-$(uname -r)

Отчет по функциям с построением callgraph:

perf report --stdio --kallsyms=/boot/System.map-$(uname -r) -g

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