Здравствуйте, Дарней, Вы писали:
Д>это как раз не "сырые" данные — ни один сервер БД не хранит данные в ASCIIZ
Как он хранит — не мое дело. А вот возвращает он из
без длины.
PD>>Давай простой пример, искусственный, конечно. Есть огромный файл (1GB , в нем одна текстовая строка, в конце ее , конечно, 0D0A . Я открываю этот файл, делаю на него MMF, позиционируюсь в конец файла, заменяю 0D на 0, имею таким образом строку ASCIIZ. Обрати внимание — файл я не читал. Все — у меня char* pString готов.
Д>а потом понадобилось добавить один символ к концу этой строки, и для этого тебе придется прочитать весь этот гигабайт в поисках маркера конца. Причем — перечитывать полностью каждый раз, как тебе понадобится добавить еще одну строку к его концу.
Д>Хороший пример ты привел, ничего не скажешь.
Бог с тобой, зачем же ? Ты вообще с MMF знаком ? Там
прямой доступ. Если уж мне надо расширить файл, то я просто создам мэппинг на размер, больший, чем текущий размер файла на требуемую величину. После чего возьму указатель, возвращаемый MapViewOfFile, приведу его к char*, добавлю к нему длину файла, получу указатель на конец данных, добавлю там что надо. Остается только закрыть мэппинг , для фала вызвать SetFilePointer и SetEndOfFile. Все. Исходный файл так и остался непросмотренным.
А даже и без MMF можно. Открываем файл, SetFilePointer на конец-1 (эта операция
не читает файл), дописываем данные, закрываем файл. Все.
PD>>Да ведь во входном мире ничего другого нет. Есть некий входной массив байт (из файла, из сети, ...). Этот набор нам дают и все. И чем-то заканчивают, чтобы знали, когда остановиться.
PD>>gets банальный, например. А дальше уж наше дело — то ли string из него соорудить, длину мимоходом посчитав и время потратив, то ли не считать длину, отложить до того момента, когда понадобится (может, и не понадобится) . Кстати, в моем примере с конкатенацией я эту длину мог мимоходом вычислить.
Д>не во входном мире, а в той библиотеке, которой ты пользуешься
Библотека откуда данные получает ? Не из входного мира ли ? ИМХО кроме как из входного мира данные брать вообще неоткуда
. А вот чтобы из входного мира строки с длиной подавали — как правило, так не делают. А если даже и сделают, это тебе не поможет в случае со string — все равно констуктор string будет исходную строку просматривать и ноль искать. По крайней мере пока это string из STL, а не что-то в Паскале, Перле и т.д.
>>>Читал историю про маляра Шлемиэля?
PD>>Нет.
Д>http://russian.joelonsoftware.com/Articles/BacktoBasics.html
Д>не наводит на размышления?
Да в общем-то ничего интересного. По крайней мере ничего нового для себя я не нашел. Довольно наивные рассуждения, особенно забавно вот это
>Строка не может содержать нулевые байты. Так что хранить произвольные двоичные данные вроде картинки в формате JPEG в строке нельзя.
Между прочим, JPEG очень неудобно хранить так же в виде стека, линейного списка, двоичного дерева и т.д. И не надо — не предназначены эти структуры для хранения JPEG
. Как и строка. Кстати, ты готов хранить JPEG в виде string ?