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. 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. Top priority, I think, is a size policy. Is Dunn's version in the Boost sandbox? Where? John Nagle Animats Reece Dunn wrote:
John Nagle wrote:
John Nagle wrote:
I've been doing some work on this too. I made char_string a subclass of a non-templated char_string_base, so you can pass references to char_string_base. This has the disadvantage of requiring a vtable, but makes the class much more useful.
I'll put this someplace publicly visible in the next day or two.
It's at http://www.animats.com/source Take a look and see if you like the direction this is going. Thanks.
Hmm. Which way to go? My latest version has been generalized to incorporate char/wchar_t support, so you can use wide-character strings. It also uses a StringPolicy class (i.e. char_traits) so you can control the length, copy, comparison, etc functions that are used.
BTW: the reason I use the const char( & s )[ m ] on compilers that support it is because this picks up the string literals in order to remove a call to strlen, thus improving performance.
Which design do you like better: using a virtual base class, or using a policy template? I have been working on providing an interface similar to std::basic_string, hence some of my latest design choices.
Ideally, the class should: * safeguard against buffer overflow on static-sized character arrays; * interoperate with classic C string operations; * interoperate with std::basic_string; * provide support for null-terminated strings and also fixed-length strings; * prevent silly mistakes by the user, ideally providing compile-time errors wherever possible.
At the moment, both implementations provide a different subset of those aims. Do you mind if I look into this and let you know what I come up with.
Regards, Reece