C++ *

Есть неупорядоченный массив arr с числами типа uint16_t. Необходимо найти количество вхождений числа v в массив arr.

int64_t cnt = 0;
for (int i = 0; i < ARR_SIZE; ++i)
    if (arr[i] == v)
        ++cnt;

------------------------------------------------------------
Benchmark                     Time           CPU Iterations
------------------------------------------------------------
BM_Count                   2084 ns       2084 ns     333079

Библиотеки с ranges

• Boost.Range
• Range V3
• think-cell public library

Прошу взглянуть на то, что из этого вышло

Начнём разбор

1) Архитектура и технические подробности

    inputNeurons = 100; 	//ширина входного слоя
    outputNeurons =2;    	//ширина выходного слоя
    nlCount = 4;			//количество слоёв ( по факту их 3, указываемое число намеренно увеличено на 1
    list = (nnLay*) malloc((nlCount)*sizeof(nnLay));

    inputs = (float*) malloc((inputNeurons)*sizeof(float));
    targets = (float*) malloc((outputNeurons)*sizeof(float));

    list[0].setIO(100,20);  //установка ширины INPUTS/OUTPUTS для каждого слоя
    list[1].setIO(20,6);	//  -//-
    list[2].setIO(6,3);     //  -//-
    list[3].setIO(3,2);     //  -//- выходной слой

• Часть первая: отрисовка стен
• Часть вторая: населяем наш мир + оконный интерфейс

• Часть первая: отрисовка стен
• Часть вторая: населяем наш мир + оконный интерфейс

Почему было необходимо интегрировать С++ библиотеку

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

Описание проблемы

На одном личном проекте на C++ мне потребовалось получать информацию о типах объектов во время выполнения приложения. В C++ есть встроенный механизм Run-Time Type Information (RTTI), и конечно же первая мысль была использовать именно его, но я решил написать свою реализацию, потому что не хотел тянуть весь встроенный механизм, ведь мне нужна была лишь малая часть его функционала. А еще хотелось попробовать на практике новые возможности C++ 17, с которыми я был не особо знаком.

В этом посте представлю пример работы с парсером libclang на языке Python.

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

Тем, кому не терпится – вот тут репозитарий на github, с подробным описанием использования. Ну а всех остальных прошу под кат…

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

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-е. А под катом пояснения и объяснения, так что кому интересно, милости прошу под кат.