Reece Dunn wrote:
Rob Stewart wrote:
From: John Nagle <nagle@animats.com>
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