Boost logo

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

> 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

Dave Abrahams
Boost Consulting