|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-02 16:42:07
Guntram Berti <berti_at_[hidden]> writes:
> On Wed, Feb 02, 2005 at 05:43:35PM +0100, Toon Knapen wrote:
>
>> So since assigning stack-based vectors of different sizes produces
>> a (compile-time) error, it is not unexpected that assigning a
>> vector (heap-based or other) to a vector of a different size
>> generates an error (compile-time or run-time): generally
>> assignments between vectors of different sizes result in an error.
>
> On first thought, I would agree with that ... having an error in one
> case (stack based) and not in the other case (heap-based) seems
> inconsistent.
>
> However, I guess that stack-based and heap-based vectors will play
> very different roles: Stack-based vectors will be small and used for
> "local" problems (e.g. 3-vectors for velocities) whereas for the
> global solution vector one would use heap-based vectors. So perhaps
> one could make the decision error-or-not a policy parameter?
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 think it will not be uncommon to wish to forbid even assignment
> between vectors of equal size, for example if one represents
> cell-based and the other one vertex-based quantities (speaking
> FEM). So one could introduce mechanisms to forbid assigment at
> compile time (i.e. making those vectors different types).
Or const?
-- Dave Abrahams Boost Consulting www.boost-consulting.com