From: John Nagle <nagle@overbot.com>
Reece Dunn wrote:
Different programmers favour the different semantics, so I ask: why not parameterise it, providing a default behaviour.
As with "do we null-terminate", I think we have to pick a behavior and stick to it. I could live with either set of semantics, but adding a parameter makes the issue more confusing.
I really don't think the two approaches are equivalent when thinking in terms of the C-string code we're trying to replace.
(And you have to supply conversions.) Most strings are sized a bit too big, anyway.
Reece mentioned that conversions, per se, weren't needed because a ctor and assignment operator can take references to the base class, thus ignoring the capacity differences. Oh, it just occurred to me that when the two have the same size, there should be a cctor and copy assignment operator to avoid the virtual function call overhead. You might even be able to do some metaprogramming to determine whether the capacity of the source string is less than or equal to the capacity of the destination string and avoid the virtual function call overhead for an entire class of copies.
On a related subject, we should have unconditional null termination. "fixed_string" items are always null-terminated. "snprintf", "strncat", etc. have hazardous semantics: if you overflow the string, it is not null terminated. (This is a bug in my current version, incidentally.) We should guarantee null termination in all cases. The whole point of this class is improved safety, after all.
Absolutely. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;