Russian Qt Forum

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

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

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

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

Боюсь, таких непосредственно в stl нет(

Не понял, зачем такой переход. В QVector, вроде, и так всё выровнено

Да, могу ошибаться, но "боковым зрением" вроде видел в мсходниках что он равняется на 16

QVector выравнивает так как выравнивается T:

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

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

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

Думаю потому что он (или его наличие) изрядно гадит в консоли, а нужда в нем возникает... "не припомина"

Я немного "потерял нить", верно ли я понимаю что нужен ф-ционал QVector<char> но с выравниванием на заданную кратность (напр 256)? Я бы объявлял вектор структур с нужным выравниванием, а для работы с char'ами, не мудрствуя лукаво, "приводился" бы (в С стиле). Можно использовать стандартное средство range (не помню как называется, множество реализаций было еще до того как оно вошло в стандарт).

Я бы смотрел в сторону сторонних библиотек.. Ну на худой конец, свой велик бы написал.. Кстати, тут товарищ,
navrocky предложил свою реализацию implicit sharing.. http://www.prog.org.ru/topic_15029_0.html (http://www.prog.org.ru/topic_15029_0.html)
Я бы там её немного бы допилил, в плане конструктора от произвольного числа аргументов..
Но как вариант, можно свою реализацию vector сделать, аналогично Qt.. 

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

Ну это не проблема сейчас? :)

Глянул в отладчике, да, "близок локоть да не укусишь". Выравнивание есть, но не видно как подлезть.

Ну а если "не по теме" :)? Верную ли цель Вы ставите (выровненный QVector<char>) и стоит ли ее добиваться? С точки зрения "минимум переделок" - скорее всего да. Но если все делать чисто/кошерно (к чему Вы так явно стремитесь) - то скорее нет. Ведь операции с QVector<char>, хотя бы push_back, erase и.т.п. никак не поддерживают целостность выравниваемых структур.

почему нельзя выделить чуть больше и использовать для доступа выровненный span<char>?

Не понял, а как он с QVector такой финт может произвести? Или я не догоняю?)

Ну типа не использовать не выровненное начало вектора, а начинать с нужным (выровненным) оффсетом. А span "мимикрирует" под вектор что позволяет АПИ сохранить более менее. Понятно, что все мутабельные операции типа append() мимо.

Спасибо, более-менее дошло)

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

С невыровненным началом - неудобно, size()/begin()/operator[],... уже непосредственно неприменимы.

Ну все-таки данные "первичны", поэтому если требование 256 установлено/принято, то и контейнер должен содержать такие структуры, с тем чтобы все операции удаления/вставки сохраняли целостность данных. А для других обработчиков соскочить на DataView (забыл как называется). Мне это кажется более идейным

Согласен с вашей логикой. По сути требования два: для определенной (математической) обработки - это выравнивание на 256 байт, для наполнения и общей обработки (типа заменить элемент) - это буфер char-ов (QVector<char>).