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

[Allen B. <al...@vr...>]

Chad Austin wrote:
> Allen Bierbaum wrote:
> 
>> I just merged my work on expression templates from the work branch 
>> into the CVS head of GMTL.
>>
>> This is a *major* feature addition and re-working of the VecBase (Vec 
>> & Point) classes and all operators that work on them.
>>
>> This change uses expression templates to remove temporary objects from 
>> expression evaluation and potentially allow compilers to better 
>> optimize the code.
>>
>> [snip]
> 
> 
> Really cool, Allen!
> 
>> The code is far from perfect though and could definitely be optimized 
>> much further.  (especially by someone that knows intel assembly and 
>> has some patience)
>>
>> There is one common compiler error to be aware of.  It is not possible 
>> to pass expression templates where VecBase/Vec/Point objects are 
>> expected.
>>
>> Details:
>>
>> GMTL makes extensive use of expression templates.  These templates 
>> come into play when evaluating statement such as:
>>
>> gmtl::Vec3f vec1, vec2, vec3;
>> vec1 = vec2 + (vec3 * 6.0);
>>
>> When evaluating the expression on the second line, GMTL creates an 
>> expression template tree to fully evaluate this expression when = is 
>> called.  The details of this process are normally hidden from the 
>> user, but can come to the forefront when a method expects a Vec or 
>> Point argument and is passed an expression.  For example:
>>
>> void myMethod(gmtl::Vec3f vec)
>> { ... }
>>
>> gmtl::Vec3f vec1, vec2;
>>
>> myMethod(vec1);           // Works correctly
>> myMethod(vec1 + vec2);    // Fails to compile
>>
>> The reason the second line fails to compile is that the type for "vec1 
>> + vec2" is not a Vec3f.  It is an expression template that describes 
>> how to sum two Vec3f's. (You may expect an autoconversion to happen, 
>> but it does not because of template argument deduction rules).
> 
>  >
> 
>> 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 anyway) or write the method to handle expression templates.  This 
>> second option is not difficult, but does require a further 
>> understanding of GMTL then is documented here.
>>
>> Here is how the first option could be used:
>>
>> myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
> 
> 
> Hm, that's really annoying...  do other math libraries that support 
> expression templates suffer from this limitation as well?  (In fact, 
> it's so annoying that I can't yet try the new gmtl out.  I don't have 
> time to update all of th places I use vectors in exactly the way that 
> breaks.)
> 

The couple that I have looked at do have this problem.  That said, if 
someone can point me at a way to work around this I would greatly 
appreciated it.

One note: Some people have found (and I have yet to test) that the above 
method doesn't have this problem unless it is templated.  (which does 
make sense).

So:

void myMethod(gmtl::Vec3f arg)

may work while

template<unsigned SIZE>
void myMethod(gmtl::Vec<SIZE,float> arg)

will not work.  So, summary: you mileage may vary right now.

-Allen





-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu