Re: [ggt-devel] GMTL: Vector expression template code checked in

[Patrick H. <pa...@13...>]

What is the fix for this:

gmtl/TriOps.h:60: error: no match for 'operator*' in 'gmtl::operator
+(const
   gmtl::VecBase<T, SIZE, R1>&, const gmtl::VecBase<T, SIZE, R2>&) [with
T =3D
   double, unsigned int SIZE =3D 3, R1 =3D
   gmtl::meta::VecBinaryExpr<gmtl::VecBase<double, 3,
   gmtl::meta::DefaultVecTag>, gmtl::VecBase<double, 3,
   gmtl::meta::DefaultVecTag>, gmtl::meta::VecPlusBinary>, R2 =3D
   gmtl::meta::DefaultVecTag]((+(+tri)->gmtl::Tri<DATA_TYPE>::operator[]
[with
   DATA_TYPE =3D double](2))) * one_third'

The code that is not compiling is this (from gmtl/TriOps.h modified to
include gmtl/VecOps.h):

template< class DATA_TYPE >
Point<DATA_TYPE, 3> center( const Tri<DATA_TYPE>& tri )
{
   const float one_third =3D (1.0f/3.0f);
   return (tri[0] + tri[1] + tri[2]) * one_third;
}

It seems as though the operator* overload in gmtl/VecOps.h isn't
matching the above for some reason, but I can't figure out why.  I've
tried calling the gmtl::Point<DATA_TYPE,3> constructor explicitly inside
the parentheses performing the point addition, but that doesn't help.
Based on what you say below, the above shouldn't be affected at all by
the changes you just checked in, but I don't have a very good
understanding of this stuff in general.

 -Patrick


On Thu, 2004-09-16 at 14:51 -0500, Allen Bierbaum wrote:
> I just merged my work on expression templates from the work branch into=20
> the CVS head of GMTL.
>=20
> This is a *major* feature addition and re-working of the VecBase (Vec &=20
> Point) classes and all operators that work on them.
>=20
> This change uses expression templates to remove temporary objects from=20
> expression evaluation and potentially allow compilers to better optimize=20
> the code.
>=20
> For example, with the previous code:
>=20
> vec1 =3D vec2 + vec3 + (vec4 * 6)
>=20
> that would have created 3 temporary vectors.  In the new code the=20
> expression templates output code that directly computes the final value=20
> from the given operands.  This has shown at least a 2x performance=20
> increase in my tests.
>=20
> The code is far from perfect though and could definitely be optimized=20
> much further.  (especially by someone that knows intel assembly and has=20
> some patience)
>=20
> There is one common compiler error to be aware of.  It is not possible=20
> to pass expression templates where VecBase/Vec/Point objects are expected=
.
>=20
> Details:
>=20
> GMTL makes extensive use of expression templates.  These templates come=20
> into play when evaluating statement such as:
>=20
> gmtl::Vec3f vec1, vec2, vec3;
> vec1 =3D vec2 + (vec3 * 6.0);
>=20
> When evaluating the expression on the second line, GMTL creates an=20
> expression template tree to fully evaluate this expression when =3D is=20
> called.  The details of this process are normally hidden from the user,=20
> but can come to the forefront when a method expects a Vec or Point=20
> argument and is passed an expression.  For example:
>=20
> void myMethod(gmtl::Vec3f vec)
> { ... }
>=20
> gmtl::Vec3f vec1, vec2;
>=20
> myMethod(vec1);           // Works correctly
> myMethod(vec1 + vec2);    // Fails to compile
>=20
> The reason the second line fails to compile is that the type for "vec1 +=20
> vec2" is not a Vec3f.  It is an expression template that describes how=20
> to sum two Vec3f's. (You may expect an autoconversion to happen, but it=20
> does not because of template argument deduction rules).
>=20
> There are two solutions to this, either explicitly construct a temporary
> object to pass to the method (which is what an auto conversion would do=20
> anyway) or write the method to handle expression templates.  This second=20
> option is not difficult, but does require a further understanding of=20
> GMTL then is documented here.
>=20
> Here is how the first option could be used:
>=20
> myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
>=20
>=20
>=20
> In closing: Give the code and try and let me know what you think. :)
>=20
>=20
> -Allen
--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/