Пусть у нас есть список — содержимое каталога, в котором элементами являются экземпляры классов 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). Все мы прекрасно знаем, что в лучшем случае сортировка вставками работает за один проход. Но в худшем ей придётся гонять по массиву столько раз, сколько в нём элементов.

1. Введение

В [1] был дан ответ на вопрос, что считать автоматным программированием (АП), но не была подробно описана модель конечного автомата (КА) в качестве модели управления автоматных программ. При этом понятно, что чистый абстрактный автомат на эту роль не годится, т.к. ограничен числом каналов. Но и структурная модель автомата, как и соответствующая ей теория структурных автоматов, не позволяют пока дать ответ по выбору модели автомата.

Проблема начинается с того, что среди множества работ по теории конечных автоматов (ТКА) мало дающих определение модели структурного конечного автомата (СКА). Правда, можно понять, что структурный автомат — это [структурная] схема из элементарных автоматов (функциональных элементов), реализующая модель абстрактного автомата [2]. Напомним, что в соответствии с теорией все начинается с создания модели устройства в форме абстрактного автомата, а затем ставится задача синтеза цифровой схемы, которая его реализует [3].

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

Правда, тут же закономерен вопрос — зачем еще один и довольно необычный «автоматный инструментарий»? На этот вопрос мы и попробуем ответить, дав определение модели [вложенного] автоматного управления, рассмотрев также ее преимущества по сравнению с обычной моделью программирования.

Всем привет. Сегодня мы посмотрим как подготовить проект с использованием библиотеки sdl2 для запуска игры на android.

В настоящей статье приводится разбор вариантов устранения антипаттерна «Зомби», описанного в первой части: Сказ об опасном std::enable_shared_from_this, или антипаттерн «Зомби».

Каждый раз, когда мы пишем класс, управляющий ресурсами, мы задумываемся о том, что, скорее всего, для него придётся писать move-конструктор и move-присваивание. Ведь иначе объекты такого типа становятся неуклюжими, как std::mutex, ими тяжело пользоваться на практике: ни вернуть из функции, ни передать в функцию по значению, ни положить в вектор — а если положить его в другой класс как один из членов, то тот класс также «заболевает».

Положим, мы преодолели свою лень (хотя в Rust таких проблем нет!) и садимся писать move-операции для нашего класса. Проблема в том, что move-семантика в C++ имеет фундаментальное ограничение: каждый владеющий ресурсами тип с move-операциями должен иметь пустое состояние, то есть состояние с украденными ресурсами. Его нужно описывать в документации и предоставлять ему поддержку, то есть тратить время и силы на то, что нам не нужно.

Для абстрактных типов данных пустое состояние обычно бессмысленно — если у объекта украли его ресурсы, то он не сможет выполнять свои обычные функции. Но мы вынуждены это делать, чтобы реализовать move-семантику. Для некоторых типов пустое состояние недопустимо: open_file (в противовес теоретическому file), not_null_unique_ptr<T> (в противовес unique_ptr<T>).

Говоря словами Arthur O'Dwyer, мы заказывали телепорт, а нам дали «вас клонируют и убивают первоначальную копию». Чтобы вернуть себе телепорт, проходите под кат!

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

Скачаем все необходимое:

Первое — это SDK для платы, которое можно скачать на официальном сайте Toradex.
Второе — нам нужен хост с Ubuntu 16.04 LTS.
Третье — непосредственно Eclipse для C/C++.

Если вы читаете этот текст – значит, вы либо подумали, что с заголовком статьи что-то не то, либо увидели в нём название знакомой компьютерной игры. VVVVVV – это инди-игра в жанре «платформер», завоевавшая сердца многих игроков своей приятной внешней простотой и не менее приятной внутренней сложностью. Несколько дней назад VVVVVV исполнилось 10 лет, и автор игры – Terry Cavanagh – отметил этот праздник публикацией её исходного кода. Что же «вкусненького» можно в нём найти? Ответ читайте в данной статье.

Одним из нововведений Visual Studio 2012 сопутствовало явление народу нового кастомизируемого отладчика под названием «Concord». Его компонентная система позволяет VSIX-плагинам подстраивать под себя поведение отладчика и писать новые, контекстно-зависимые, инструменты, которые могут эксплуатировать отладчик для своих нужд. Его API предоставляет множество QOL фич, таких как маршалинг между управляемым/неуправляемым кодом, бесшовная интеграция с удалённо/локально отлаживаемым процессом, и не только. По сути, практически всё, что можно сделать в IDE, можно сделать программно, используя Concord API! Менять на лету значения конкретных переменных, вызывать по заказу функции (или специально заставлять программу пропускать вызовы оных!), плагинам доступен поиск по PDB (!), пошаговый обход и даже модификация кода! Открой кат, и ты узнаешь об этих малоизвестных инновациях в области велосипедостроения.

gRPC — опенсорсный фреймворк для удаленного вызова процедур. В Яндекс.Маркете gRPC используется как более удобная альтернатива REST. Сергей Федосеенков, который руководит службой разработки инструментов для партнеров Маркета, поделился опытом использования gRPC в качестве протокола для построения интеграций между сервисами на Java и C++. Из доклада вы узнаете, как избежать частых проблем, если вы начинаете использовать gRPC после REST, как возвращать ошибки, реализовать трассировку, отлаживать запросы и тестировать вызовы клиентов. В конце есть неофициальная запись доклада.

— Сначала хотелось бы познакомить вас с некоторыми фактами про Яндекс.Маркет, они будут полезны в рамках доклада. Первый факт: мы пишем сервисы на разных языках. Это накладывает требования по наличию клиентов для сервисов.