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 following example: 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 #include <boost/units.hpp> #include <boost/liear_agebra.hpp> int main() { // 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 squared). 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 types. Does MTL4 already take care of that? -- Janek Kozicki |