Does ostringstream have a max size?

[Armitage]

I have an intermitant problem where an ostringstream object ends up with a size of 0 when it should be quite large. I regularly use them with lengths up to about 75K characters, but I suspect I'm getting an occasional occurence where it's overflowing or such.

It's no problem to cut down the size, I'd just like to know what the limit is so I can limit it appropriately.

 

[singh]

No (it should not). Do you have a sample program that could demonstrate this problem? Is this a multi-threaded program by any chance? Also, what compiler/platform are you using?

 

[Armitage]

Originally posted by: singh
No (it should not). Do you have a sample program that could demonstrate this problem? Is this a multi-threaded program by any chance? Also, what compiler/platform are you using?

g++ 3.3.1 on Linux/X86

It is a mutithreaded program, and no I don't have a simple example to demonstrate it.

Basically, this thread reads a queue of objects (with appropriate locks around it) that need to be pushed into the database, builds the insert query, and runs it.

The object queue can stack up pretty good sometimes, and if the insert query is to big, the DB server has fits. So there's a loop in here that builds queries for 100 objects at a time. I use and ostringstream object to build them.

On rare occasions, when I go to run this query at the end of this loop over 100 objects, the ostringstream object (qstr) is empty (qstr.str.size() = 0), despite the fact that I know it went through the loop that builds the queries 100 times, and that it had some length before it started the loop - I push the beginning of the query - "INSERT INTO sieve_results VALUES" before the loop to actually add the data.

When I run this query it generally has a size on the order of 70,000

After each query, I reset the ostringstream object with

qstr.seekp(0);
qstr.str("");

I have a run going now that shows the size of the ostringstream object during the course of that 100-long loop to see what's happening inside. But as I said, it's a relatively rare occurence, so it may take awhile to find a case.

 

[Armitage]

Psuedocode...

 

[Armitage]

Ok, I figured it out.
If you reset the stringstream twice in a row, it somehow crashes the stream. This can happen in my code if you happen to get a local_queue length that is a multiple of 100 :roll:

Is there a better way to clear & reset an ostringstream object then the seekp(0)/str("") combination?

 

[singh]

Use clear() to reset internal flags. If this still causes problems, don't reuse the same object; just allocate a new one when you need it.

 

[Armitage]

Originally posted by: singh
Use clear() to reset internal flags. If this still causes problems, don't reuse the same object; just allocate a new one when you need it.

clear() is inherited from ios - it resets the control states but not the contents of the buffer.

Your right - I could just discard it at the end of each iteration. Just seems dumb to have to do that.