From: "Reece Dunn" <msclrhd@hotmail.com>
Rob Stewart wrote:
From: "Reece Dunn" <msclrhd@hotmail.com>
Rob Stewart wrote:
From: "Reece Dunn" <msclrhd@hotmail.com>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;