|
Boost : |
From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-13 08:22:41
From: David Abrahams <dave_at_[hidden]>
> John Nagle <nagle_at_[hidden]> writes:
>
> > If you're willing to accept a call to "new", you can just
> > use std::string and reserve some initial size.
>
> It's not the same thing. You might only be willing to accept a call
> to "new" if things go beyond a certain length. That's *usually* the
> only reason I'd ever have a fixed-size buffer. Very occasionally
> I'll be in code that where I don't want to throw an exception, but
> then a string that responds to overflow by throwing is no better.
char_string can throw a more meaningful exception than
std::bad_alloc.
In the small string optimization or std::string with reserve
approaches, the buffer grows when the input is too large, and
other, downstream code may overflow or behave badly. Stopping
the overflow early may be better and having an automated
mechanism for preventing overflow is wise.
> > So you don't need that capabiilty in char_string. char_string is
> > for situations when you don't want to invoke dynamic allocation at
> > all. In desktop applications, that's not too common, but in real
> > time work, inside operating systems, and in embedded applications
> > it's not unusual.
>
> I'm saying, it's almost always better to degrade performance
> gracefully as the program's input grows than it is to introduce an
> execution discontinuity like an exception (if possible). In many of
> those scenarios you've named, exceptions, like dynamic allocation have
> been banned anyway for similar real and/or imaginary reasons.
There's probably room and need for both types of strings.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk