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?
yup. The idea is to make it a buffer-overflow safe replacement for C style character buffers, e.g.: char buf[ 100 ]; ::sprintf( buf, "...", ... ); while allowing it to behave like a basic_string.
strings be similar? If the STL string operations are to be meaningful, they have to be.
Only if you want to apply mutating algorithms that modify size. IOW, it isn't unreasonable to choose either fixed-size or fixed-capacity strings. If the former, then there are no mutating algorithms that affect the size. If the latter, the size can change, but an exception occurs when trying to exceed the capacity.
That's the way I see it, but instead of throwing an exception, the class simply prevents overrun and fills the available space, e.g.: char_string< 5 > buf; buf.copy( "Meine Grosse Welt!" ); std::cout << buf << '\n'; // prints "Mein" (null terminated)
In STL strings, "size" doesn't include a trailing null. Using "c_str" can result in expanding the string to add a trailing null. With fixed-size strings, we don't have that option.
If c_str is provided, there must always be space for a trailing null. So you can't use char_string when you need a specific fixed length, as for Macintosh 4-character file signatures. Perhaps "boost::array<char>" is the way to go for that sort of thing. Trying to do both null-terminated and non-null-terminated strings in the same class will get ugly.
If the string if 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.
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.
That is a good idea. It will mean keeping track of the string length, but it does permit both versions without requiring complex internals/semasntics or seperate classes. In order to keep interoperability with C style usage (i.e. operator const char *()), we can have the following: inline const char_type * c_str() { // null-terninate buffer: str[ len ] = char_type( '\0' ); return( str ) } inilne operator const char *() { return( c_str()); } Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband