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 _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger
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
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?
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.
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. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (3)
-
John Nagle -
Reece Dunn -
Rob Stewart