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

[Sokoloff]

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

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

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

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

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

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

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

[Litkevich Yuriy]

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

В качестве промежуточного хранилища могу ещё назвать QTemporaryFile, кажется так называется

[Sokoloff]

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

В качестве промежуточного хранилища могу ещё назвать QTemporaryFile, кажется так называется

Да нет, никаких особых причин нет, оптимизацией я пока еще не занимался, хотя и особых тормозов не видно. Это "по молодости и от излишнего усердия"©, т.е. маловато опыта и перфекционизм терзает
Ладно по другому задам вопрос, есть в QT какой-то стандартный/распространенный метод передачи большого блока (до 1 мегабайта) не юникодного текста.

[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

[Sokoloff]

(до 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, то практически все они показали одинаковые результаты, т.е. тролли уже оптимизировали.

В том-то и дело, что я не знаю размер буфера, это будет зависеть от того, какой postscript попадется, один мегабайт, это я так примерный-максимальный размер указал, а так, кто знает какого размера будет одна страница постскрипта.
Я чего пристаю. Теоретически я понимаю, что при добавлении к QByteArray данных, будет выделяться новый блок памяти суммарного размера и копироваться данные, что не оптимально, но это в теории. Но на практике полно ситуаций когда оптимальность приносится в жертву простоте, вот и спрашиваю, как на на практике замарачиваются с такими вещами или не забивают себе голову?
Опять же, использование функции QByteArray::reserve дает "better performance" а вот насколько better?

[LE0N]

Мне вот чего не понятно. Почему ты так боишься динамического распределения памяти? Не умеешь с ней работать?
Если есть данные переменной длины, то здесь два варианта:
1) Динамическое распределение
2) Выделение МАКСИМАЛЬНОГО количества памяти.
----------
Чего ты ждёшь от форумчан?
И что значит "я не знаю длины этих данных" ? То, что данные имеют переменную длину, и её узнать можно во время выполнения? Или то, что ты вообще не знаешь их количество и не можешь определить его даже во время выполнения программы?
ЗЫ. Копирование данных в оперативной памяти занимает минимум времени. А если ещё и динамическое распределение умное написать, так вообще огонь будет...

Сообщение отредактировал LE0N - 17.4.2009, 8:03

[Litkevich Yuriy]

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

[igor_bogomolov]

Стратегии увеличения размера
Sokoloff, возможно вы уже это читали, если нет, то будет очень интересно.

[SABROG]

Я для работы писал программу еще 2 года назад и мы её используем. Но я писал её тогда еще на Borland Builder C++. Тогда мне казалось, что для данных выкаченных с SQL сервера мне хватит 1Гб памяти. Со временем количество данных расло и дорасло до 5Гб, т.е. уже полезло в своп и программа начала падать с out of memory. В итоге перешел на ifstream/ofstream. Сначала данные записываю во временный файл (в поток), а потом его читаю (из потока). В результате скорость работы программы несколько упала, но зато позволила делать работу.

[Sokoloff]

Гигабайтов быть не может, это все-таки рендер постскрипта.
Временный файл, имеет смысл использовать для хранения данных, получили данные, сохранили в файл и некоторое время их используем. У меня же, хранения нет: нажали на кнопку, прочитали одну или несколько PS страниц, обработали, передали в рендер, и временный файл здесь IMHO лишний.
Всем спасибо за ответы, решил остановиться на QBuffer, и не забивать себе голову.