ограничение на размер буфера в strstream

Я сейчас на BCC55 попробовал - всё вроде в порядке, length = 387. Только using namespace std бы не помешало...

по-видимому stormbringer не понимает разницу между stringstream и strstream. хотя оба предоставляют сходный интерфейс для форматирования потоков, второй является средством вывода в буфер выделяемый программистом (один из аргументов конструктора) и поэтому не меняющим свою длину самопроизвольно в процессе вывода тогда как первый обладает этим качеством (и насколько я знаю, пока не реализован для egcs)

Вот результаты расследования с использованием Интернета (не хочется тратить $18 на стандарт) и header'ов к bcc5.5:

strstream и stringstream отличаются в основном только тем, что первый работает над char*, а второй - над string'ами. Поэтому второму не нужен ends на конце строки, в частности.

Есть небольшие разницы в семантике (см. ссылочку).

strstream & friends считаются устаревшими (deprecated).

Ссылочка:
http://home.camelot.de/langer/Papers/IOStreams/IOStreams.htm (внизу)

Еще немного информации по теме. В последнем издании Страуструпа описан только stringstream, а про strstream упоминается мимоходом, что они "были частью изначальной библиотеки потоков" и что они полезны при работе с устаревшими программами. Тем не менее, в хедерах gcc 2.95.2 и egcs 2.91 такой штуки, как stringstream, вообще нет. Есть только declaration *strstream, в обоих случаях одинаковый. Программа, которую вы привели в самом начале, на обоих компиляторах работает интуитивно правильно ( то есть выдает length=387 ).

2stormbringer: попробуй заодно и это:

#include <iostream> 
#include <strstream> 
#include <string.h> 
int main() 
{ 
  strstream str; 
  for (int i=0; i<100000; i++)
    str << i << ' '; 
  str << std::ends; 
  cout << str.str() << endl << "length = " << strlen(str.str()) << endl; 
  return 0; 
}

у меня на RH6.2 (egcs-2.91.66) всё работает! твой вариант работает тоже,
свой я проверил специально чтобы убедиться, что буфер не выделяется на
этапе компиляции (у тебя длина буфера могла бы элементарно вычисляться по
длине строковых литералов, в моём случае это сделать для не известного
при компиляции верхнего предела счётчика цикла невозможно -- добавь
ввод предела сам)

что должно работать железно (выделение памяти программером):

char buf[число];
ostrstream os(buf,число);
// ну и т.д.

То ли я когда-то ткнулся личиком в постоянство длины буфера вывода
(по-моему это было в RH5) то ли меня самого вели в заблуждение
-- на чём ты проверяешь? (кто-нибудь знает -- в GNUшном компайлере 
по-жизни strstream позволял выводить данные произвольной длины не требуя
выделения памяти со стороны программера или это появилось позже?)

Ах да, с Новым Годом!

Всем с Новым Годом и ОГРОМНОЕ СПАСИБО! Для filin: хотя я не понимаю разницу м/у strstream & stringstream, strstream также динамически выделяет память. ;) Пришу прощения у всех, я еще недавно в мире OpenSource, поэтому не прояснил проблему. Так вот, есть C++ враппер для MySQL API, называется MySQL++. Он работает нормально на gcc 2.95.2, но не хочет на моем 2.96 от RedHat 7.0, поэтому я нашел его старую версию (в которой все работало), и начал "доводить" ее до уровня последней версии. А там как раз класс SQLQuery наследуется от strstream для возможности легкого построения запроса, смотрите сами как это удобно: int GID, RID; string name; ... GID = RID; query << "update " << name << " set GID=" << GID << " where RID=" << RID; query.execute(); Так вот, из-за ОШИБКИ РЕАЛИЗАЦИИ старой версии MySQL++ там в query нельзя было запихать более ~100 символов, что после 3х дней разборок я и исправил.

2stormbringer: я это уже понял, иначе бы не орал что всё работает (и это для меня было новостью). Насчёт динамического выделения, в случае "ostrstream os(buf, число)" память динамически выделять не надо -- она уже выделена программером. Разница между strstream и stringstream на g++ не актуальна ввиду отсутствия второго (что я уже заметил выше).