[boost] Re: static sized strings

From: John Nagle (nagle_at_[hidden])
Date: 2004-05-13 12:54:25

Reece Dunn wrote:
> Rob Stewart wrote:
> 
>> From: John Nagle > Reece Dunn wrote:
>> > > Rob Stewart wrote:
>> > >> From: John Nagle
>> The question is, which is better: char_string<4> or
>> boost::array<char,4>?  I suggest that the latter is better.  In C
>> code, and similar C++ code, arrays of char are used as buffers of
>> fixed length and as memory for strings.  Code will be clearer if
>> one uses boost::array<char,N> for the former and char_string<N>
>> for the latter.  Once you make that distinction of purpose, null
>> termination can be integral to char_string without complication
>> or unwanted overhead.
> 
> That makes sense.

    Agreed.  If you're doing something that requires an
array of characters of a specific size, it's often
part of some structure defined by some external standard,
like a Macintosh file signature or an ISO CD header.
There, you need something that contains exactly the
characters specified, and nothing else.
"boost::array<char,N>" is thus the right tool for that job.
> 
>> > What about the base class issue?  There's a need to be able to
>> > write something like "char_string_base& s" when you want to
>> > pass around fixed-capacity strings of more than one capacity.
>>
>> If that is a necessary feature, then the length can be stored in
>> the base class.  However, such a base class means that the dtor
>> must be virtual.  Is vtable overhead acceptable in such a class?
>> Perhaps two types are needed.
> 
> 
> My design does not use a virtual base class, so that isn't an issue. 
> John Nagle's version does, so that is where the problem arises. I have 
> several issues with the use of a virtual base class:
> 
> [1] If you want to operate on a variable length character string 
> specifically, why not templatize the function:
>   template< int n >
>   void myfn( boost::char_string< n > & s ){ ... }

    That leads to templatizing every function that has
a char_string argument, with the associated headaches
and overhead.  It's not easy to retrofit that to
existing code without a major rewrite.  With a base
class approach, you can just replace "char *"
with "char_string_base&", then fix any compile
errors, and your program becomes buffer overflow safe.
That's easy to do.
 
> [2] How do you deal with wide-character strings? My update generalizes 
> to support char and wchar_t based buffers, but with a virtual base 
> class, you are limited to char buffers.

    I'm assuming that wchar_string will be much like char_string,
but may be a separate file.  The functions it has to call 
(strncat vs. wstrncat) have different names, so you can't just
crank out both forms with a template anyway.

> [3] One of the reasons for having a virtual class is to supply custom 
> string operations, e.g. using Windows-specific string functions instead 
> of the standard library ones. This can also be solved with a policy 
> template like that found in basic_string. My current version uses this 
> approach, improving interoperability with basic_strings.

    Did you ever put this in the Boost sandbox?

                                John Nagle