From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-28 07:47:10
From: John Nagle <nagle_at_[hidden]>
> 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.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk