From: John Nagle (nagle_at_[hidden])
Date: 2004-05-10 15:44:59
Reece Dunn wrote:
> John Nagle wrote:
>
>> There are fundamental issues with string size that have to be
>> resolved.
>>
>> 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
OK. That yields good semantics.
> null character is always added
What do you do for "operator[]" and "at"?
> fixed size (fixed_string< n > s)
> size() = capacity() = n;
As long as that's a different type, fine.
>> 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.
>
>
> 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.
OK.
>
>> 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).
That's probably better handled with a different type than
with a boolean template parameter.
We should get as close as possible to a drop-in replacement
for C strings. That's needed and will get used. In general,
either it should just work, or you should get a compile error,
when you substitute "char_string<N> s" for "char s[N]" and
"char_string_base&" (or whatever is chosen) for "char *".
That makes this a widely useful tool rather than an exotic one.
This is looking much better than it did in the first draft.
John Nagle
Animats