[boost] Re: static sized strings

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