Re: [boost] [Review] Fixed Strings review period extended

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-30 17:15:12

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message 
> news:87slr5bu6z.fsf_at_boost-consulting.com...
>> "Paul A Bristow" <pbristow_at_[hidden]> writes:
>>
>>> | -----Original Message-----
>>> | From: boost-bounces_at_[hidden]
>>> | [mailto:boost-bounces_at_[hidden]] On Behalf Of Hartmut Kaiser
>>> | Sent: 29 January 2006 23:31
>>> | To: boost_at_[hidden]
>>> | 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