|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-03 09:17:36
Guntram Berti <berti_at_[hidden]> writes:
> On Wed, Feb 02, 2005 at 04:42:07PM -0500, David Abrahams wrote:
>
>> Guntram Berti <berti_at_[hidden]> writes:
>>
>
>> 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.
>
> Reducing complexity is certainly a design goal we should keep in mind.
> Maybe the solution proposed by Karl (AssignmentAdapter) helps to keep
> such decisions localized. However, I think/wish there should be the
> possibility to fit in user-defined/configured vector types into the
> general framework.
Of course there will be; this is a generic framework. So then the
question becomes: is assignability between vectors of different sizes
part of the vector _concept requirements_. To that, my answer would
be "clearly not, because we can't support it for statically-sized
vectors."
> So people who do not use extra features like checking can go with a
> low-complexity plain vector, while others use that feature-laden
> mega-vector :-)
> I also agree that we should collect much more examples before making a
> final decision here.
Use cases tell all.
>> > 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?
>>
>
> No, because I still want to be able to assign vectors of the same
> (mathematical!) 'type'. Assignment is really just a special case:
> Think of operations like addition where we also will have to
> carefully decide which combinations are allowed and which are not.
> "Same c++ type" is not the only useful criterion here.
It's usually the best one. Vectors et al. are "scalar" quantities
(like pi). You can always add type information later per
http://article.gmane.org/gmane.comp.lib.boost.devel/117232
-- Dave Abrahams Boost Consulting www.boost-consulting.com