Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-10 14:00:13


From: John Nagle <nagle_at_[hidden]>
>
> STL strings are variable-sized, with no limit. When you
> add characters, "size()" increases. Should fixed-size
                                                    ^^^^
I presume you're referring to fixed-capacity strings which can
have a variable size, right?

> strings be similar? If the STL string operations are
> to be meaningful, they have to be.

Only if you want to apply mutating algorithms that modify size.
IOW, it isn't unreasonable to choose either fixed-size or
fixed-capacity strings. If the former, then there are no
mutating algorithms that affect the size. If the latter, the
size can change, but an exception occurs when trying to exceed
the capacity.

> In STL strings, "size" doesn't include a trailing null.
> Using "c_str" can result in expanding the string to add a
> trailing null. With fixed-size strings, we don't have that
> option.
>
> If c_str is provided, there must always be space
> for a trailing null. So you can't use char_string
> when you need a specific fixed length, as for Macintosh
> 4-character file signatures. Perhaps "boost::array<char>"
> is the way to go for that sort of thing. Trying to do
> both null-terminated and non-null-terminated strings
> in the same class will get ugly.

If the string if fixed-capacity *and* there remains sufficient
capacity, c_str() can null terminate the buffer. If there isn't
sufficient remaining capacity, then throw an exception.

IOW, make it a runtime error to fix the capacity too small to
permit null termination when calling c_str(). That still leaves
room for things like the 4-character file signature to which you
referred, and yet prevents buffer overrun, but doesn't require
foregoing flexibility.

-- 
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