Re: [boost] Re: static sized strings

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-05-27 16:56:35

Rob Stewart wrote:
>From: "Reece Dunn" <msclrhd_at_[hidden]>
> > Rob Stewart wrote:
> > >From: "Reece Dunn" <msclrhd_at_[hidden]>
> > > > John Nagle wrote:
> > [snip]
> > I think you misunderstand what I am trying to say. See my comments 
>below.
>
>Actually, I think you misunderstood my points.

ok.

> > [1] You need to specify the size of the buffer. You cannot declare an 
>object
> > of type fixed_string_base (as it is abstract), you can only have 
>references
> > and pointers to it so you can operate on variable-capacity strings.
>
>Ah, but you missed that I was declaring a fixed_string_base,
>where string capacity is not known.  I was relying on
>make_fixed_string() to deduce the array length and create an
>appropriate fixed_string for it.

I didn't miss it, just misunderstood what you intended.

> > [2] This is the point that we are discussing. Should this line be:
> >
> >    fixed_string< LENGTH > t;
> >
> > as will work with the current sandbox implementation (my suggestion #2), 
>or
> > should it be:
> >
> >    fixed_string< LENGTH + 1 > t;
>
>And that's exactly my point.  It should be the former as shown by
>my equivalencies.
>
> > Different programmers favour the different semantics, so I ask: why not
> > parameterise it, providing a default behaviour.
>
>I'm not so sure they do and I'm not sure you need to allow for
>it.  If you do, I suspect you'll encourage off-by-one mistakes.
>Granted, those mistakes won't result in overruns, but they will
>be annoying.  Furthermore that will result in different
>fixed_string types; will you provide for conversions among them?
>(That is, for example, from a fixed_string that adds one to the
>capacity to one that doesn't?)

It is the former in the implementation I have, but if you have
   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. This would transfer to the other model.

> > >(I know there is no make_fixed_string() -- yet -- but such a
> > >facility would be appropriate.)
> >
> > Er... the fixed_string constructors! When you declare the object, you 
>should
> > know the size of the buffer you are using, e.g.:
> >
> >    fixed_string< 100 > data;
>
>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 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.

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:

   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.

Regards,
Reece

_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger