Oh, you illustrated several problems
max was the least of them.
Thanks for the tip on the updated streams. I can't say they're an improvement though.
Item 1: YTF did they blend istream and ostream in stringstream? Can you use it as a queue? Will it block on reads or throw an exception? We already have pipes for this stuff.
Item 2: The new version is written in terms of string. This is OK, but string does heap allocation all the time so for small buffers its likely to suck compared to stack memory. You'll note that in my code I don't need to call str or freeze as I already have the buffer. So it looks like streaming to a known memory location is no longer supported. So much for high performance code.
Item 3: You can construct one with no buffer (it'll use a string) or a const string&. Nifty. Suppose I want to stream into my own string. I'll miss WriteStream on: myString.
WTF are this people thinking?
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
Oh, you illustrated several problems
max was the least of them.
Thanks for the tip on the updated streams. I can't say they're an improvement though.
Item 1: YTF did they blend istream and ostream in stringstream? Can you use it as a queue? Will it block on reads or throw an exception? We already have pipes for this stuff.
Item 2: The new version is written in terms of string. This is OK, but string does heap allocation all the time so for small buffers its likely to suck compared to stack memory. You'll note that in my code I don't need to call str or freeze as I already have the buffer. So it looks like streaming to a known memory location is no longer supported. So much for high performance code.
Item 3: You can construct one with no buffer (it'll use a string) or a const string&. Nifty. Suppose I want to stream into my own string. I'll miss WriteStream on: myString.
WTF are this people thinking?
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
