1. Введение

Конкурентная борьба за умы, настроения и чаяния программистов является, как мне представляется, современным трендом развития программирования. Когда почти не предлагается ничего нового, хотя и под лозунгом борьбы за него. Распознать в толчее программных парадигм что-то новое, которое на поверку часто оказывается достаточно известным а, порой и просто устаревшим, весьма и весьма сложно. Все «замыливается» терминологическими изысками, многословным анализом и многострочными примерами на множестве языков программирования. При этом упорно обходятся просьбы открыть и/или рассмотреть подоплеку решения, суть нововведений, пресекаются в зародыше попытки выяснить насколько это нужно и что даст в итоге, что качественно отличает нововведение от уже известных подходов и средств программирования.

UPD: благодаря помощи Tkachov эта статья всё-таки превратилась из просьбы о помощи в работающую инструкцию. В комментариях он дал работающий код для создания игнора в десктопном клиенте Телеграм. Я на всякий случай расположу объяснение в конце статьи. Далее статья продолжается в том же виде, в каком была написана.
UPD: Сделал «сайт» для распространения готового приложения sites.google.com/view/ignoram

* * *

Я хотел бы попросить помощи у сообщества, потому что все собственные возможности я полностью исчерпал.

Можно было бы задать вопрос на сервисе Q&A (он же бывший Тостер) — только я это уже сделал, и пользы вышло не очень много.

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

Если повезёт, то кто-нибудь в комментариях подскажет решение. И тогда нашедшие эту статью в поисковиках тоже смогут эту проблему решить.

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

Иногда, определенных успехов можно добиться, выполнив оптимизацию CMake. Рассматриваемый здесь прием основывается на простой идее: две статические библиотеки, использующие функции друг друга, могут собираться одновременно.

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

Под «Филвордом» я буду иметь ввиду эту многим знакомую игру.

В игре есть поле размером обычно NxN заполненное словами. Наша цель — найти все слова.
В нашей версии не будет букв в поле, которые не принадлежат ни одному слову и служат для сбивания игрока, а также не будет букв, которые принадлежат сразу нескольким словам. Обычный классический Филворд. И так, задача поставлена. Нужно решать.

Первым делом я всегда разбиваю задачу на подзадачи. Для решения этой задачи мне понадобится:

1. БД со словами.
2. Алгоритм, который вставляет слова в поле.
3. Алгоритм, который проверяет выбранное пользователем слово на корректность. К примеру мы в поле поместили слово «программирование», а пользователь увидел там «мир» и выделяет это слово. Пользователь прав – такое слово есть, но мы его не загадывали. Нам нужен алгоритм, который будет проверять догадки пользователя и говорить ему прав он или нет.

Все, игра простая поэтому пунктов тоже не много. Начнем выполнять по порядку.

1) БД со словами.

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

Вопрос о многопоточности задают даже далёкие от разработки люди, когда речь заходит о производительности 3D-приложений, в частности систем проектирования (САПР). Поддержка многопоточности закладывается в геометрическом ядре системы. Поэтому мы решили на своём примере показать, какие механизмы для этого разработаны и как они помогают использовать многопоточные вычисления в 3D-приложении.

Этот пост подготовила Татьяна Митина, сотрудник C3D Labs, в прошлом Intel (читатели Хабра знакомы с ней по истории «Мне 57 лет, и я scrum-мастер»).


Модель завода с технологическим оборудованием в КОМПАС-3D
ООО «ОКБ» (Новосибирск)

Версии 16.3 и 16.4 Visual Studio 2019 принесли много новых улучшений в качестве генерации кода, пропускной способности сборки и безопасности. Если вы еще не загрузили свою копию, вот краткий обзор того, что вы упустили.

1. Введение. Конкурентный корутинизм

Предыдущие статьи на тему автоматного программирования были всего лишь «цветочками». «Ягодкой» автоматного программирования, т.е. ради чего нужно им заниматься, является модель параллельных вычислений на базе модели конечных автоматов. Итак, поехали…

Стандарт С++ включил в свой состав долгожданную поддержку многопоточности [1]. Но не будем ни восхищаться этим, ни критиковать сей факт, т.к. работа с потоками отягощена таким множеством условий, оговорок и особенностей, что без реальных примеров, выявляющих проблемы многопоточности, обсуждение многопоточного программирования будет не только поспешным, но и достаточно предвзятым. Поэтому далее в основном не о потоках, а об автоматах, имея в виду, конечно, и первые.

Зачем и для чего

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

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

Впервые на похожую задачу я наткнулся на прошлой работе. К слову, решена эта задача была методом 3 из данной статьи. «Как неэстетично», — подумал я. — «Дали бы мне эту задачу, я бы точно решил ее в 128 раз лучше. Но… как?»

С той поры минуло уже 5 лет, а я, время от времени мысленно возвращаясь к данной задаче, так и не придумал к ней идеального решения. Тем не менее, за это время у меня успело накопиться несколько идей, которыми я хочу с вами поделиться.

Введение

Целью данной статьи является продемонстрировать способ как можно подружить сторонние видео буфера и QML. Основная идея — использовать стандартный QML компонент VideoOutput. Он позволяет подсовывать сторонние источники, неплохо документирован и имеет бекэнд поддерживающий GL_OES_EGL_image_external.

Мысль, что это вдруг может быть полезно, возникла после того, как я попытался запустить примеры работы с камерой в Qt, и на embedded платформе они работали со скоростью 3-5 кадра в секунду. Стало ясно, что из коробки ни о каком zero-copy речи не идет, хотя платформа все это отлично поддерживает. Справедливости ради, на десктопе VideoOutput и Camera работают, как и положено, быстро и без лишних копирований. Но в моей задаче, увы, нельзя было обойтись существующими классами для захвата видео, и хотелось завести видео из стороннего источника, каким может быть произвольный GStreamer пайплайн для декодирования видео, к примеру, из файла или RTSP стрим, или сторонний API который интегрировать в базовые классы Qt несколько сомнительно. Можно еще, конечно, в очередной раз переизобрести велосипед и написать свой компонент с рисованием через OpenGL, но это сразу показалось заведомо тупиковым и сложным путем.

Все вело к тому, что нужно разобраться как же оно устроено на самом деле, и написать небольшое приложение подтверждающее теорию.

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

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

void f(int i){}
void f(string s){}

vector<int> int_c = { 1, 2, 3, 4, 5 };
vector<string> string_c = { "Sic" ,"transit" ,"gloria" ,"mundi" };
for_each(begin(int_c), end(int_c), f);//error C2672: "for_each": не найдена соответствующая перегруженная функция

Как известно, приложения написанные на Qt, который является кросс платформенными запускаются от desktop, мобильных, интернет вещей, до микроконтроллеров.

Один из вариантов это сборка приложения Qt в WebAssembly — которое позволит Вам запускать его в браузере у пользователя. Таким образом обновление приложения для пользователя будет заключаться в загрузке на сервер нового файла wasm.

Чтобы легче было осуществлять деплой приложения, в рамках данной статьи давайте соберём приложение Qt в WebAssembly под Windows в командной строке.

История, как это часто бывает, началась с того, что упал один из сервисов на сервере. Точнее процесс был убит мониторингом за превышение использования памяти. Запас должен был быть многократным, а значит у нас утечка памяти.
Есть полный дамп памяти с отладочной информацией, есть логи, но воспроизвести не получается. То ли утечка безумно медленная, то ли сценарий зависит от погоды на Марсе. Словом, очередной баг, который не воспроизводится тестами, но встречается в дикой природе. Остаётся единственная реальная зацепка — дамп памяти.

В самый канун Нового года увидела свет новая версия главного инструмента Intel для разработчиков — Intel Parallel Studio XE 2020. Давайте воспользуемся этим поводом и посмотрим, чем живет сейчас всем известная «студия» и в какую сторону развивается.

SObjectizer — это относительно небольшой C++17 фреймворк, который позволяет использовать в С++ программах такие подходы, как Actor Model, Publish-Subscribe и Communicating Sequential Processes (CSP). Что существенно упрощает разработку сложных многопоточных приложений на C++. Если читатель в первый раз слышит о SObjectizer-е, то составить впечатление о нем можно по этой презентации, или из этой уже достаточно старой статьи.

Вообще говоря, подобных открытых, все еще живых и все еще развивающихся инструментов для C++ не так уж и много. Можно вспомнить разве что QP/C++, CAF: C++ Actor Framework, actor-zeta и совсем молодой еще проект rotor. Выбор есть, но не сказать, что большой.

Недавно стала доступна очередная "мажорная" версия SObjectizer-а, где наконец-то появилась штука, о которой разговоры ходили давно, и к реализации которой я несколько раз безуспешно подступался. Можно сказать, что достигнута знаковая веха. Это также повод, чтобы рассказать о том, что ждет SObjectizer после релиза версии 5.7.0.

Поддержка send_case в select()

Итак, самое важное нововведение, которое появилось в v.5.7.0 и ради которого даже сломана совместимость с вышедшей в прошлом году v.5.6 (а совместимость мы просто так не ломаем) — это поддержка send_case в функции select(). Что сделало SObjectizer-овский select() гораздо более похожим на select из языка Go. Теперь посредством select() можно не только читать сообщения из нескольких CSP-шных каналов, но и отсылать исходящие сообщения в те каналы, которые оказались готовы для записи.

При работе приложения с оконным интерфейсом важно обеспечить отсутствие зависаний. Для этого сложные вычисления стоит запускать в отдельной нити. Концепция многопоточного приложения отлично сочетается с подходом сигналы-слоты Qt, при этом совершенно не нужно переопределять никакой метод run().

Основная идея. В многопоточном приложении вычисления проводятся в отдельной ните, по окончанию излучается сигнал, передающий результат в своих аргументах. Слот, принадлежащий уже MainWindow, будет вызван. Результаты вычислений окажутся в аргументах слота и не составит труда вывести их.

Я хотел написать этот пост ещё в июле, но никак не мог, о ирония, решить, как его назвать. Удачные термины пришли мне в голову только после доклада Кейт Грегори на CppCon, и теперь я наконец могу рассказать вам, как не надо называть функции.

Бывают, конечно, названия, которые вообще не несут информации, типа int f(int x). Ими пользоваться тоже не надо, но речь не о них. Порой бывает, что вроде бы и информации в названии полно, но пользы от неё абсолютно никакой.

Привет, Хаброжители! Язык С++ выбирают, когда надо создать по-настоящему молниеносные приложения. А качественная конкурентная обработка сделает их еще быстрее. Новые возможности С++17 позволяют использовать всю мощь многопоточного программирования, чтобы с легкостью решать задачи графической обработки, машинного обучения и др. Энтони Уильямс, эксперт конкурентной обработки, рассматривает примеры и описывает практические задачи, а также делится секретами, которые пригодятся всем, в том числе и самым опытным разработчикам.

В книге • Полный обзор возможностей С++17. • Запуск и управление потоками. • Синхронизация конкурентных операций. • Разработка конкурентного кода. • Отладка многопоточных приложений. Книга подойдет для разработчиков среднего уровня, пользующихся C и C++. Опыт конкурентного программирования не требуется.

Многие программисты думают, что Quick Sort — самый быстрый алгоритм из всех существующих. Отчасти это так. Но работает она действительно хорошо только если правильно выбран опорный элемент (тогда сложность составляет O (n log n)). В противном же случае асимптотика будет примерно такой же как и у пузырика (то-есть O (n²)).
При этом, если массив уже отсортирован, то алгоритм всё-равно будет работать не быстрее, чем O (n log n)

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

«Дело было вечером, делать было нечего», — Сергей Михалков.

Требования:

1. Лучший случай O (n)
2. Средний случай O (n log n)
3. Худший случай O (n log n)
4. В среднем быстрее быстрой сортировки

А теперь давайте обо всём по порядку

Чтобы наш алгоритм всегда работал быстро, нужно чтобы в среднем случае асимптотика была хотя бы O (n log n), а в лучшем — O (n). Все мы прекрасно знаем, что в лучшем случае сортировка вставками работает за один проход. Но в худшем ей придётся гонять по массиву столько раз, сколько в нём элементов.