"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87slr5bu6z.fsf@boost-consulting.com...
"Paul A Bristow" <pbristow@hetp.u-net.com> writes:
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser | Sent: 29 January 2006 23:31 | To: boost@lists.boost.org | Subject: [boost] [Review] Fixed Strings review period extended
As another silent downloader, I just want to agree that we really do need a fixed_string,
Why?
Usage of big stack buffer for string formatting was (is?) usual practice in C programming.
Sure. That doesn't make it right. It's the cause of innumerable bugs, and not just overrun errors. The bjam sources (written in 'C') used to do this, and it made bjam completely non-scalable. I ripped all the fixed buffers out and replaced them with a proper variable-sized string "class" (written in 'C') that uses the small string optimization, and it works great. If I had used some kind of fixed-sized buffer there would have remained all kinds of edge cases where the code stopped working. If you're going to go through code and replace fixed-sized char arrays on the stack with something more reliable, it makes no sense at all to go halfway and use something that is still going to give you problems when your input data is larger than you might have anticipated (or whatever). Just use a class that can grow as necessary.
Especially for error message formatting. Nowadays need for stack_string (which IMO would be a better name) is unclear. In practice it's just an attempt on performance improvements.
Right. Start with the SSO on a general-purpose string class. If you find yourself needing larger statically-allocated buffers for efficiency reasons, add a template parameter that allows you to specify the static buffer length. How many applications do you think would find that arrangement to be still too inefficient?
I guess it could be useful in performance critical areas where need for dynamic allocation could hurt.
This is a .01% optimization. Profile first and prove that dynamic allocation hurts. Use a large SSO buffer so you have dynamic allocation as insurance. If, after you've gone through all that care to determine that you really need a fixed-sized character array, you can afford to be careful enough with those few lines of code to make it right.
An alternative is having std::string somewhere cashed.
??
But we a) may not place for it b) still do not want to depend on performance on dynamic clear/resize methods.
I don't understand. -- Dave Abrahams Boost Consulting www.boost-consulting.com