From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-08-30 17:38:43
David Abrahams said: (by the date of Wed, 30 Aug 2006 15:26:43 -0400)
> Without knowing the details of your library, a well-designed generic
> library usually defines non-intrusive concepts that allow any type to
> satisfy the requirements, given some additional traits and functions.
> There should be no need to write a new quaternion.
with the context of physical units I would like to point to you
A function somewhere in the MTL4 library, with following signature:
vector<3,T> operator*(vector<3,T> lhs, T rhs) // multiply vector by scalar
return vector<3,T>(lhs.x*rhs, lhs.y*rhs, lhs.z*rhs);
// now the testing code
// disclaimer: of course implementation details of unit and
// linear_algebra libraries are unknown, for the sake of this example I
// had to make some assumptions when writing it.
vector<3,boost::unit::length::m> v(10,20,30); // unit [meter]
boost::unit::length::m k(3); // unit [meter]
typedef length_squared boost::unit::squared<boost::unit::length::m>::value_type; // unit [meter^2]
vector<3,length_squared> result=v*k; // error !!
As you can see the return type in this case is different than the type
of arguments supplied. Because from type T we get to type T*T (meter
The impact of this "error" is huge. It means that return types of all
functions in MTL4 library are not straightforward - they must be
appropiately calculated by the compiler.
In above example the return type is a result of multiplicating two
Does MTL4 already take care of that?
-- Janek Kozicki |
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk