Glas List: Re: [glas] MTL3 design ? [was MTL project site is up]

From: Theodore Papadopoulo (Theodore.Papadopoulo_at_[hidden])
Date: 2005-02-03 08:17:40

David Abrahams:
> I won't consider introducing checking in MTL until there is an example
> of a kind of problem it can prevent that is more serious than the
> inconvenience the checking introduces.  Introducing a checking policy
> parameter has yet another disadvantage: increased complexity.  Don't
> underestimate this -- it creeps everywhere, including tests and docs.
> So the problem prevented by checking would have to be more serious
> than the inconvenience and the complexity.

I just do not understand.... Maybe we are not speaking of the same thing ??
What complexity is increased in disallowing assignments for vectors of different sizes.
In any case you have to check that you have enough memory to do the copying. The mere difference is that 
disallowing it you just use an assert like line, while to authorize it you need to do the size test and add some 
memory management code (freeing the previous memory, allocating the new one).

Actually complexity and cost are increased by allowing assignments for vectors of different sizes (unless there is 
some black magic somewhere I do not know of). Less constraints also means more testing...
So again, where is the inconvenience and the complexity.

Also, how do you believe that allowing assignment of different sizes vectors would give any flexibility.

As for how it can prevent a problem, just consider how difficult it can be to find a write past the end of an array and how
easily it could have been caught by one global size check... If a user has a mathematical vector in mind, he also has
a size in mind... so having the size changed in an assignment behind his back is error prone. The nice thing with asserts is
that you are not obliged to pay the price for the checks once your code is debugged.

Rainer Blome:
> 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.

I fully agree with what you said (the full mail)...
I would add that since the goal is to design a linear algebra library, the good way to start is to have
a look at several linear algebra algorithms (blas/lapack of course or gsl or ...) and to make the list of all
the operations that are needed to implement such algorithms (at least those used more than once).
Then we have a basis for discussing what should be the properties of matrix/vector containers.

Designing the container before knowing its properties is the wrong way of doing things...

        Theo.