|
Boost : |
From: John Nagle (nagle_at_[hidden])
Date: 2004-05-12 16:59:52
Reece Dunn wrote:
> Rob Stewart wrote:
>
>> From: John Nagle <nagle_at_[hidden]>
>> >
>> > STL strings are variable-sized, with no limit. When you
>> > add characters, "size()" increases. Should fixed-size
>> ^^^^
>> I presume you're referring to fixed-capacity strings which can
>> have a variable size, right?
Yes.
> yup. The idea is to make it a buffer-overflow safe replacement for C
> style character buffers, e.g.:
>
> char buf[ 100 ];
> ::sprintf( buf, "...", ... );
Yes.
>> If the string if (sic) fixed-capacity *and* there remains sufficient
>> capacity, c_str() can null terminate the buffer. If there isn't
>> sufficient remaining capacity, then throw an exception.
Done that way, if you write
char_string<4> s;
strcat(s,"ABCDE"); // truncates at "ABCD", no null.
printf("s=%s\n",s.c_str()); // c_str throws exception
which is quite different from classic <string.h> semantics.
You couldn't use that as a drop-in replacement for C strings.
Nor is it compatible with STL basic_string semantics.
I'd suggest consistent null-terminated semantics for char_string.
>> IOW, make it a runtime error to fix the capacity too small to
>> permit null termination when calling c_str(). That still leaves
>> room for things like the 4-character file signature to which you
>> referred, and yet prevents buffer overrun, but doesn't require
>> foregoing flexibility.
If you want a 4-char file signature, you can use
"boost::array<char,4>", which does that job. Is there any
real need for that functionality in char_string?
char_string might have some convenience template functions to
interconvert "boost::array" and "boost::char_string".
> That is a good idea. It will mean keeping track of the string length,
Yes, that seems to be necessary.
What about the base class issue? There's a need to be able to
write something like "char_string_base& s" when you want to
pass around fixed-capacity strings of more than one capacity.
> Regards,
> Reece
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk