Reece Dunn wrote:
John Nagle wrote:
There are fundamental issues with string size that have to be resolved.
STL strings are variable-sized, with no limit. When you add characters, "size()" increases. Should fixed-size strings be similar? If the STL string operations are to be meaningful, they have to be.
The way I see it, size() relates to the current size of the string, and capacity() relates to the current storage size, thus you have: --
null-terminated, fixed size (char_string< n > s) size() = strlen( s.c_str()); capacity() = n; string manipulations guaranteed such that size() < capacity() in order to cope with null character
OK. That yields good semantics.
null character is always added
What do you do for "operator[]" and "at"?
fixed size (fixed_string< n > s) size() = capacity() = n;
As long as that's a different type, fine.
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.
size() will not include the trailing null; c_str() will return the character buffer; null character is added by the string operations, thus there is no need to add it on the c_str() operation.
OK.
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.
I don't think it will be that ugly. In a previous post that contained the updated char_string class, I had an implementation of it as a boolean template parameter (null-terminate).
That's probably better handled with a different type than with a boolean template parameter. We should get as close as possible to a drop-in replacement for C strings. That's needed and will get used. In general, either it should just work, or you should get a compile error, when you substitute "char_string<N> s" for "char s[N]" and "char_string_base&" (or whatever is chosen) for "char *". That makes this a widely useful tool rather than an exotic one. This is looking much better than it did in the first draft. John Nagle Animats