Hello,
I believe the code below shall run forever but it shall not consume more and more memory as Windows task manager shows. This problem occures for your standard library that is shipped with Microsoft Developer Studio 2005. The earlier versions seem to be unaffected.
#include <sstream>
int
main() {
for(;;) {
std::stringstream ss;
ss << "asdf";
}
}
--
Michael Kochetkov
P.S. I have reported it to Dinkumware with their bug report form too but then I have thought about posting it here.

stringstream loses memory
Matthew Mitrik MSFT
It's a known bug slated to be fixed in half a year in SP1
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=153610&SiteID=1
abc4567
Perhaps as the string stream is going out of scope on each loop, it's also cleaning up after itself on every loop In that case, the old version is the bug, surely
I didn't know that dinkumware still does the STL for VC++ I knew they did for VC6, the really terrible version that everyone replaced in order to use it
Todd Potter
Does this mean when the original poster said
but it shall not consume more and more memory as Windows task manager shows.
he meant it SHALL consume more and more memory I thought he was saying that constantly streaming to the stringstream didn't consume memory when it should ( which would mean the stream was not working at all ).
angrycoder2
> Does this mean when the original poster said
> but it shall not consume more and more memory as Windows task manager shows.
> he meant it SHALL consume more and more memory I thought he was saying that constantly streaming to the
> stringstream didn't consume memory when it should ( which would mean the stream was not working at all ).
Eh, English lessons are too far behind and I sould probably have used "and it shall not consume ..." instead of "but..." but I have thought these conjunctions were synonyms in that very case.
--
Michael Kochetkov
Dmitriy Nikonov MSFT
I'm sorry, I'm not trying to pick on your English. I just wanted to clarify, because it seems to me that you're saying it DOES consume more and more memory, and I wanted to understand the question better.
Raj
Ooops,
it is too late in my local place now and was too inattentive not to check the http://lab.msdn.microsoft.com/productfeedback/ViewWorkaround.aspx FeedbackID=FDBK40119#1
I was just thinking "with my hands" on the problem for a long time trying to find out the fault of my own instead of being sure I just cannot be wrong (as I do most of the time :) ).
OK, I am going to rebuild it tomorrow. Sorry for hasty post.
--
Michael Kochetkov