Да, нужен  QVector<char>, такой что первый байт всегда лежит по адресу, кратному 256 (или любому другому, задаваемому статически). Структура байт в векторе - это уже будет двумерный индекс.

Разумеется, иначе что это за контейнер, которой кладет на заданное выравнивание типа. Он волен нижнюю границу поднять (например, минимум 16 байт) из-за каких-то своих соображений, но опустить - никак. Также и нижележащие malloc/realloc не опускаются ниже определенной величины.

Собственно, если нужно иметь выровненный буфер как таковой, хранящийся в векторе, то достаточно как-то так:
Но работать с ним поэлементно через интерфейс QVector нельзя: v[1] вернет 257 байт, а не второй.

Для поэлементной работы с байтами можно грубо пропатчить индексный доступ, но тут уже семантические нарушения по типу:
Это все костыли. Нужно просто, чтобы у QVector был аллокатор. Кстати, как думаете - почему его нет? Полагаю, что Qt-контейнеры создавались прежде всего для собственных нужд (типа хранить чилдренов, небольшой мапчик/хэшик и т.п.), где аллокаторы не нужны.

Ревизирую старый код, и стоит вопрос рефакторинга QVector->std::vector (также рассматривается std::array для некоторых случаев). Мотивация - иметь выровненные данные в контейнере для последующей оптимизации (векторизации, и в этой связи также рассматривается замена double -> float).

Основная семантическая проблема - использование в QVector Implicit Sharing (copy-on-write) при передаче данных, в основном, между потоками.

Собственно, вопрос - нужен stl::vector c Implicit Sharing семантикой, в идеале - совместимой с Qt, т.е.:

Порекомендуйте хорошие порты STL или просто отдельные библиотеки STL-контейнеров, наделенные данным свойством.

Я вовсе не агитирую за агульное применение! Просто проиллюстрировал, что подобный функционал (постановка потока на паузу) востребован.

Возможно, лет через 5 увидим.

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

processEvents(): навскидку, нужно запилить свой эвент диспатчер (наследник QAbstractEventDispatcher), который будет иметь режим извлечения и обработки событий поштучно, т.е. QAbstractEventDispatcher::processEvents() будет извлекать одно событие и возвращать управление. По MouseRelease будет возможность завершить драг перед обработкой последующих событий, например, Esc keypress, которое в противном случае отменило бы завершившийся драг.

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

Скорость переключения? Cерьезно?.. ~ 2000 аccемблерных инструкций на x86 (переход в режим ядра), то же, что и у Sleep.

Ну, например, в Win API есть ref-counted SuspendThread/ResumeThread. Элементарный юзкейс - например, вычисляете 10-ю потоками некое сложное значение, юзер ждет, но решает поставить операцию на паузу и выполнить другое жирное вычисление.

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

Как ваше стекло соотносится с флагами Qt::WindowTransparentForInput, Qt::WA_TransparentForMouseEvents, Qt::WA_NoMousePropagation?

Для некоторых алгоритмов фатальный недостаток QtContainers - нет возможности выравнивания данных (нет аллокатора, идущего параметром шаблона в контейнерах stl).

Как уже здесь многие отмечали, концепции этой "корутины" уже сто лет в обед. Мейнстрим практика - например, в Win32 API, начиная с NT 3.51, есть функция CreateFiber (читай корутина), которая в свою очередь создавалась с целью облегчения портирования Unix-овых программ под Windows. Соответственно, в Unix-ах это API появилось ... даже не знаю когда.

Востребованность? А часто ли требуется ручное переключение контекста? Часто ли вы использовали setjump/longjump? Ну если только вы пишите специфичный инструментарий, манипулирующий контекстом, например, такой как обработка исключений (есть разные реализации, в т.ч. через setjump/longjump).

template<class T>
bool SameValue( const QVariant & v, const T & value )
{
   return v.canConvert<T>(value) && (v.value<T>() == value);
}

Подниму тему - как сейчас обстоят дела Qwt vs Qt Charts vs QCustomPlot vs ...? Доработан ли Qt Charts для комфортного использования ран-тайм отрисовки графиков (например, сигнал со звуковухи)?

От себя добавлю - в 2016 довольно основательно выбирал Qt-friendly библиотеку для отрисовки 2D реал-тайм графики (сигналы, спектрограммы и т.п.), да и всякие контролы типа потенциометров тоже были весьма желательны. Qt Charts тогда было платно, малофункционально и, как я тогда предположил, не слишком шустро для рантайм отрисовки. QCustomPlot интерфейсом был неплох, но серьезно проигрывал Qwt в быстродействии - там при просмотре исходников это сразу стало понятно. Чего то другого стоящего не нашел, поэтому выбор пал на Qwt.

Qwt, в принципе, меня удовлетворила. Имеет продуманный объектный дизайн, допускающий широкую кастомизацию (чуть ли не каждый объект в итоговом композите, например, таком как QwtPlot, можно заменить кастомным), код весьма качественный. Документация - средняя. Примеры базового использования в комплекте (большой плюс). Есть поддержка от самого автора, отвечает оперативно и предметно даже на вопросы типа "А как мне сделать так-то и так-то". На баги - еще быстрее.

В плане быстродействия либа не слишком оптимизирована, - например, для получения каждой точки отрисовываемой кривой вызывается виртуальная функция, но эта плата за абстракцию и функциональность (в плане расширения). Если провести сравнительную параллель - то это как если бы в STL был базовый класс контейнера с виртуальными/абстрактными функциями-членами типа operator[] и абстрактными итераторами, и std::vector наследовался бы от этого базового контейнера.

Однако, после небольшой собственной оптимизации (QwtPlotOptimizedCurve) в купе с кастомными QwtSeriesData, QwtRasterData и т.п., берущими данные из циклических буферов, получил приемлемую скорость рантайм отрисовки (обновление с частотой ~10-20 Гц - большей глазу и не нужно) даже на ARM v7 linux-девайсах. Каких-то серьезных багов не обнаружил, утечек памяти - тоже (специально не искал, но сутками работающее приложение оставалось с тем же потреблением). Так что ставлю Qwt 4 из 5 - из-за неоптимизированности для ран-тайм отрисовки и местами скудноватой документации.

Друзья, все так, спасибо!

Студия с аддоном уже при открытии pro-файла замусоривает сорцы.

ИМХО, если в pro-файле задавать выходные папки сборки, то там должны быть только относительные пути (относительно корня проекта), чтобы было максимально портабельно.

В Qt проекте, который собирается из QtCreator или из ком. стороки, используется теневая сборка, т.е. вне папки исходников. Для использования MSVC его solution генерируется так:
При этом сборка из MSVC IDE происходит в папке исходников. Как задействовать теневую сборку, чтобы не править вручную сгененрированные файлы проекта MSVC, в идеале - задать теневую сборку в ком. строке вызова qmake выше?

В принципе, запуск qmake из другой директории, поддиректории, например, частично решает проблему:
Сорцы, находящиеся в папке ..\src не засоряются.

Оно как! Спасибо.