Re: [boost] Re: static sized strings

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-28 07:42:17

From: "Reece Dunn" <msclrhd_at_[hidden]>
> Rob Stewart wrote:
> >From: "Reece Dunn" <msclrhd_at_[hidden]>
> > > Rob Stewart wrote:
> > > >From: "Reece Dunn" <msclrhd_at_[hidden]>
> > > > > John Nagle wrote:
> 
>    char data[ 100 ];
>    // manipulate and use the data buffer
> in this example, the buffer is 100 characters, but only 99 are writable, 
> with the 100th being a null character (assuming this is a C-style string).
> 
> Using the current implementation, this would lead to
>    fixed_string< 100 > data;
> having an extra character.

That's the usage I suggested should be relegated to boost::array:
it is a data buffer, not a string.

> >The problem is that you don't know the length of the string.
> >That is, with this code:
> >
> >    char s[] = "1234";
> >
> >s is a fixed size array of char with five elements.  The
> >programmer didn't have to write:
> >
> >    char s[5] = "1234";
> >
> >Instead, the compiler figured out the length.
> >
> >That's what I'm trying to provide an equivalence for:
> >
> >     fixed_string_base & s = make_fixed_string("1234");
> >
> >With that approach, the client doesn't need to precompute the
> >length of the literal and can rely on the compiler (and template
> >magic) to deduce it and use it to create a fixed_string<5>.
> >
> >I've shown returning by value (with the temporary bound to the
> >reference s), but it could return a smart pointer just as well.
> 
> Your original example didn't have fixed_string_base as a reference. It 
> should be easy to implement a make_fixed_string function.

I'm not surprised.  I wasn't concentrating on real semantics so
much as suggestive ones.  Note, however, that one has to prevent
copying among fixed_string_bases to avoid slicing.

> > > >I think this clearer reveals that fixed_string's size parameter
> >                 ^^^^^^^
> >That should have been "clearly."
> >
> > > >should specify the number of characters.  Remember, one can use
> > > >boost::array to manage a fixed size, non-string buffer.  If
> > > >buffer overrun protection is insufficient in boost::array, that
> > > >should be fixed (or a new class should be added to Boost).  Thus,
> > > >fixed_string can ignore that usage.
> 
> I am not disputing this. The question is, is the null terminator counted as 
> a character. For the example you show, it is, but for buffers (see the 
> example above) it isn't.

Right.  I'm emphatically voting for declaring the type with the
length of the string; the class adds space for the terminator.

> I haven't got a conversion between the two models because I am only 
> implementing the one model at the moment, but conversion would be automatic 
> because the functions that take strings as arguments take fixed_string_base 
> & arguments, so they should be usable regardless, consider:

Makes sense.

>    boost::fixed_string< 20 > str1( "This is a long string!" );
>    boost::fixed_string< 10 > str2;
>    str2.assign( str1 );
> 
> This will work (cutting the string short in str2) even though the strings 
> are of different capacities.

Good, that's exactly what should happen.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;