After substitution the generic expression usually becomes an expression for which we can
compute a result. Depending on the type of this result, different evaluation strategies have to
be chosen. For the case that it is a user-defined class that supports the expression template
functionality, we have to allow for the possibility of some existing sophisticated evaluation
strategies that only the user's class is aware of. Thus, evaluation should remain the user's
class' responsibility. For all other cases we can do evaluation on our own.
It is not only the result type that has to be taken into accout. The program context plays an
important role, because an expression either needs to be evaluated, or has to become part of
another expression:
using LAMBDA::x;
using LAMBDA::y;
Vec3 a,b,c,d;
cout << lambda(x,y, x + y)(a,b); // evaluation
cout << lambda(x,y, x + y)(a,b) - c + d; // become part of new expression
Of course lambda(x,y, x + y)(a,b) - c + d should yield the same code as a + b - c + d
does. Immediately evaluating lambda(x,y, x + y)(a,b) - thus, returning a Vec3 object -
is not a good idea at this point, because some benefits of the expression template technique may get lost.
Notice, that if directly evaluating the lambda term, the two examples will lead to different expression
objects. In the first case (lambda(x,y, x + y)(a,b) - c + d), the lambda term is evaluated first
and the result of adding a and b as well as c and d will
become part of the expression object. In the second case (a + b - c + d ) all four Vec3
variables will occur in the expression object. Thus, possibe optimization steps cannot include the a + b
part of the expression. A better solution is to make lambda(x,y, x + y)(a,b) part of a new expression
template tree.
The easiest way to make this possible is to wrap the result obtained by applying a function
returned by lambda into PETE's Expression class template. The wrapped class template
(called FACT_PETE_ROOT) stores a SIGNATURE object (according to the
types/values that have been passed to lFUNC's function call operator)
and the generic expression object that originally has been passed to lambda.
As already mentioned above, the return type of an expression has influence on the evaluation
strategy. To determine it, we first perform substitution and then traverse the expression template
tree with PETE's meta program ForEach. The result type is computed bottom up: at each
node a template meta program computes the return type according to the type of the node's childrens
and the type of operation stored at the the node. This operation already has been discussed in the
PETE's section and is selected by the OpCombine tag.
To do compuatation at the leafs, FACT! provides the GetLeafType tag along
with the following specialization of the LeafFunctor struct:
template<typename T>
struct LeafFunctor<T,GetLeafType> {
typedef T Leaf_t;
static inline Leaf_t apply(const Leaf_t& l,const GetLeafType& t) {
return l;
}
};
Computing the result type ResultType for an expression E finally looks
like this:
typedef ForEach<E,GetLeafType,OpCombine>::Type_t ReturnType;
Once the return type is known, we have to check whether it is a class that offers expression template
functionality. As mentioned in earlier, this functionality depends on the existence
of a specialization of CreateLeaf. If no such specialization exists,
PETE wraps values into the Scalar template before storing them in the expression tree.
Thus, we just have to check whether CreateLeaf<ReturnType>::Leaf_t is equal to Scalar<ReturnType>.
If not, we safely can assume ReturnType to be aware of expression templates.
For the case that ReturnType offers expression template functionality we suppose
it to provide a constructor template that constructs a user object from an Expression<>
object and return an appropriate temporary (see CLE2E below). Otherwise, we use PETE's
forEach function to traverse the expression tree and perform computations according to
the operators stored at the nodes. At the leafs we use the leaf-functor tag EvalLeaf1
to access the values.
The following code section shows the complete code for the meta program RetFLA
which selects the correct evaluation strategy for an expression type:
struct mTRUE {};
struct mFALSE {};
template < typename COND,typename THEN,typename ELSE>
struct mIF { typedef THEN Type_t; };
template < typename THEN,typename ELSE >
struct mIF<mFALSE,THEN,ELSE> { typedef ELSE Type_t; }
template < typename T1,typename T2 >
struct mEQUAL { typedef mFALSE Type_t; };
template < typename T >
struct mEQUAL<T,T> { typedef mTRUE Type_t; };
template < typename E,typename R >
struct CLE2N {
static inline R apply(const E& e) {
return forEach(e,EvalLeaf1(0),OpCombine());
}
};
template < typename E,typename R >
struct CLE2E {
static inline R apply(const E& e) {
return R( e.expression() );
}
};
template <typename E,typename R>
struct RetFLA {
typedef typename mIF< typename mEQUAL<typename CreateLeaf<R>::Leaf_t,
Scalar<R>
>::Type_t,
CLE2N<E,R>,
CLE2E<E,R>
>::Type_t Type_t;
};
Evaluating an expression e of type E now simply means to call
RetFLA<E,ReturnType>::apply(e);.
The remaining question is where to initiate the evaluation process. Usually, evaluation
is triggered through a call to an assignment operator, which only can be overloaded through the definition
of a class member function. Overloading the assignment operator for built-in types is not supported by C++.
Also, a similar operation is needed to allow assignment from a built-in type that is obtained through the
application of a function that was returned by lambda, like for instance in int i = lambda(x,y, x + y)(2,3).
A possible solution is to equip Expression<FACT_PETE_ROOT> with a conversion
operator that allows objects of this type to be converted into the ResultType that is
related to the expression:
template <typename E,typename S>
struct Expression< FACT_PETE_ROOT<E,S> > {
...
typedef ForEach<E,GetLeafType,OpCombine>::Type_t ResultType;
operator ReturnType() const {
return RetFLA< E,ResultType>::apply(*this);
}
...
};
Finally, we can give the return type of lFUNC2's function call operator:
template < typename A1,typename A2>
Expression< FACT_PETE_ROOT< E, SIGNATURE<A1,A2> > > operator()(A1 a1,A2 a2) {
...
}
