From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-05-10 14:10:20
John Nagle wrote:
> There are fundamental issues with string size that have to be
> STL strings are variable-sized, with no limit. When you
>add characters, "size()" increases. Should fixed-size
>strings be similar? If the STL string operations are
>to be meaningful, they have to be.
The way I see it, size() relates to the current size of the string, and
capacity() relates to the current storage size, thus you have: --
null-terminated, fixed size (char_string< n > s)
size() = strlen( s.c_str()); capacity() = n;
string manipulations guaranteed such that size() < capacity() in order to
cope with null character
null character is always added
fixed size (fixed_string< n > s)
size() = capacity() = n;
> 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
size() will not include the trailing null; c_str() will return the character
buffer; null character is added by the string operations, thus there is no
need to add it on the c_str() operation.
> 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.
I don't think it will be that ugly. In a previous post that contained the
updated char_string class, I had an implementation of it as a boolean
template parameter (null-terminate).
> Top priority, I think, is a size policy.
Do you mean how to handle size() and capacity()? If so, see above.
> Is Dunn's version in the Boost sandbox? Where?
I have not yet added it to the sandbox, but will in the next few days.
Stay in touch with absent friends - get MSN Messenger
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk