Glas List: Re: [glas] Design Principles

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-03 09:13:23

"Rainer Blome" <rainer.blome_at_[hidden]> writes:

> Hi.
> 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

  vector newx(y);

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?

Let's add:

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