From: John Nagle (nagle_at_[hidden])
Date: 2004-05-10 13:13:46
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.
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
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.
Top priority, I think, is a size policy.
Is Dunn's version in the Boost sandbox? Where?
Reece Dunn wrote:
> John Nagle wrote:
>> John Nagle wrote:
>>> I've been doing some work on this too. I made char_string
>>> a subclass of a non-templated char_string_base, so you can
>>> pass references to char_string_base. This has the disadvantage
>>> of requiring a vtable, but makes the class much more useful.
>>> I'll put this someplace publicly visible in the next day
>>> or two.
>> It's at
>> Take a look and see if you like the direction this is going.
> Hmm. Which way to go? My latest version has been generalized to
> incorporate char/wchar_t support, so you can use wide-character strings.
> It also uses a StringPolicy class (i.e. char_traits) so you can control
> the length, copy, comparison, etc functions that are used.
> BTW: the reason I use the const char( & s )[ m ] on compilers that
> support it is because this picks up the string literals in order to
> remove a call to strlen, thus improving performance.
> Which design do you like better: using a virtual base class, or using a
> policy template? I have been working on providing an interface similar
> to std::basic_string, hence some of my latest design choices.
> Ideally, the class should:
> * safeguard against buffer overflow on static-sized character arrays;
> * interoperate with classic C string operations;
> * interoperate with std::basic_string;
> * provide support for null-terminated strings and also fixed-length
> * prevent silly mistakes by the user, ideally providing compile-time
> errors wherever possible.
> At the moment, both implementations provide a different subset of those
> aims. Do you mind if I look into this and let you know what I come up with.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk