Rob Stewart wrote:
From: "Reece Dunn" <msclrhd@hotmail.com>
Rob Stewart wrote:
From: "Reece Dunn" <msclrhd@hotmail.com>
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