|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-02-03 10:48:59
On Thu, 3 Feb 2005, David Abrahams wrote:
> 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."
Well, it would be possible to introduce a refined 'resizable vector'
concept. But that is unnecessary, because I think (?) we're really
only talking about operator= for concrete container types, where it is
purely up to whoever implements the operator as to whether they allow
resize or not. A _concept_ for resizable vectors would only be useful if
you wanted to delegate resizing from a proxy type to the underlying
container, such as
vector<complex<double> > x(10, complex<double>(1,1));
vector<double> y(20, 5);
real(x) = y; // would implicitly resize vector x to length 20
But that IMO is nuts.
OTOH, disallowing resize-on-assignment for concrete containers sounds
masochistic to me. The performance argument has no credibility - the cost
is a single comparison (size == Other.size) and I suspect that this is the
sort of precondition check that would slip under the radar. I've always
had such precondition checks in my codes, and I've never seen them appear
on a profile. Has anyone else? (this is not a rhetorical question, its
obvious that different problem domains use vectors/matrices in different
ways...)
>
> > 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
Heh, we enter the world of overlapping/conflicting definitions. But I
agree completely. A vector is a simple abstraction for a function from
a (finite, contiguous) set of integers to some type T. Anything beyond
that belongs elsewhere.
Cheers,
Ian