Буфер для обмена между классами Опции

[Sokoloff]

Вот подскажите как лучше сделать.

Есть 2 класса один генерит постскрипт, и передает его во второй класс, которй рендерит этот ps с помощью ghostscript.
Вопрос в том, как лучше передавать постскрипт, что использовать в качестве буфера.

Варианты QString и QByteArray я сразу отверг, т.к постскрипт в первом классе генериться по частям (отельно заголовок, отдельно тело и.т.д.) и общий размер я заранее не знаю, а перевыделять память при каждом добавлении IMHO это не хорошо.

Вариант с QStringList вроде очевиден, класс специально создан для хранения больших текстовых данны. Но, внутри у него QString, т.е. используется UTF16, а postscript это ASCII, ghostscript тоже принимает char*, соответственно имеем лишний расход памяти, и ненужное преобразование ASCII->UTF16->ASCII. Не аккуратненько как-то.

Можно использовать QList<QByteArray>, вроде никаких проблем, но не так очевидно как с QStringList.

Еще есть вариант (и он, даже, практически готов), это не использовать буфер вообще, а внутри первого класса, а для каждого кусочка постскрипта вызывать метод фторого класса и передавать в него этот кусок. Но что-то мне кажеться что это лишнее усложнение логики.

Вот поскажите как лучше сделать, что использовать в качестве буфера, или это все мелочи и я просто парю себе мозг?

[SABROG]

(до 1 мегабайта)

Сначала хотел предложить QTextStream и файл, но раз заранее известно, что максимум 1Мб, то скорее всего такие варианты:
QBuffer
QByteArray - сразу выставить размер в 1Mb (это смешно по современным меркам, когда firefox кушает 200-300Мб). Далее append()
QList<QLatin1String> - позволит избавится от насильной перекодировки в unicode. QStringList - синоним QList<QString>. Удобно добавлять через оператор <<
static unsigned char array[1048576] = {0} - стандартный байтовый массив и Си строки.

P.S.: если скорость критична, то я бы попробовал все варианты и сравнил. Но как правильно кто-то сказал "преждевременная оптимизация - в большенстве случаев лишняя трата времени, которое могло бы уйти на что-то более полезное".
Например сегодня я наткнулся на такую статью про Qt - http://www.kdedevelopers.org/node/3663. Если вкратце, то человек замерил скорость заполнения/стирания области (rect) и написал свой алгоритм, который делает это быстрее чем Qt. В итоге, когда я прогнал эти тесты на Qt 4.5, то практически все они показали одинаковые результаты, т.е. тролли уже оптимизировали.

Сообщение отредактировал SABROG - 16.4.2009, 22:01