Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk