Re: [glas] Design Principles
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-03 09:13:23
"Rainer Blome" <rainer.blome_at_[hidden]> writes:
> Related to the discussion whether assignment of vectors of different sizes should be allowed,
> I think it would help to identify a number design principles that may help to decide issues like this.
> Examples would be (some taken from postings):
> David Abrahams> will it [a safety measure] prevent enough bugs
> to justify the inconvenience?
> Toon Knapen> if [a feature] is done under the hood, people will be surprised
> by the performance(-penalties) they get.
> Theodore Papadopoulo> catch [...] problems as soon as possible.
> My 2 pennies:
> o Avoid implicit conversions, they will hurt you (performance- and
> safety-wise). Instead, make explicit conversions easy.
Nobody's talking about implicit conversions here AFAIK.
> o If it's not required, it should not have to be paid for.
> Stay "Lean and mean".
> For example, a program that does not benefit from the convenience
> of implicit resizing should not have to pay the prices of it
> (performance hit, less errors caught at compile time, etc.).
I'd be interested in what the "etc." stands for because your other two
points against implicit resizing are -- with all due respect -- bogus.
Nobody has demonstrated that implicit resizing causes a performance
hit as compared to whatever code you'd need to do the same thing
without having the resizing capability. If I were to write:
x = y;
and that was to cause a size compatibility error, then typically I'd
need to write
instead, which is clearly more expensive.
Certainly there's always some performance hit for checking and
reporting errors; classifying fewer things as errors is one way to
avoid taking that hit [though I'm not convinced that hit is any worse
than the small one required to decide whether to allocate new memory
in case the target is being resized].
We're only talking about implicit resizing for types where the size
can't be part of the type, so there would clearly be exactly the same
number of errors caught at compile-time.
> o Make things explicit in general, enable the programmer to express
> her thoughts.
Good one; I support that idea. But how does forbidding
x = y;
when x and y have different sizes enhance expressivity?
o Do not make unsupportable claims about the costs/benefits of various
design choices ;-)
I do not have a very strong position about whether implicit resizing
is a good idea. Certainly, my arguments about convenience are weak
and will only become clearly wrong or right after I've done some more
design work. I do have a very strong position about the basis on
which design decisions are made. I will not introduce either
avoidable design complexity or avoidable runtime errors without some
very clear evidence that there's a benefit. So far I've heard a lot
of vigorous agreement that resizing should be disallowed, and one
vague reference to a real-world case where it might have helped with
something (not sure what yet). The former leaves me mostly unmoved;
I'm still interested in the latter and any other arguments for or
against implicit resizing.
-- Dave Abrahams Boost Consulting www.boost-consulting.com