[boost] Re: Are You interested in boost::etl, a reusable Expression Template Library?

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2003-05-14 03:40:53

Pierre Aubert wrote:

> Markus Werle écrivait: > Hi!
>  > 
>  > While writing (and reading) code which uses the Expression
>  > Template technology I encountered a lot of code repetition.
>  > The task of providing a code base for the representation of
>  > expressions by nested types has to be done over and over again.
>  > 
> 
> You can have a look at meta::expr<T>, which is a slightly
> different from PETE.
> 
> https://sourceforge.net/project/showfiles.php?group_id=2326

[ Sorry, I was out of office for a while ]

IMHO Daixtrose is more extreme here: there is no member function
(like e.g. print()) besides the content-getters within the classes 
that serve as building blocks for the nested template 
representation of the expression. 

This has some advantages. First of all, since evaluation of an 
expression is strictly separated from expression representation,
the core code base is likely to become very stable, mature,
even in the presence of feature changes.

Second, since the classes are lightweight, optimizers 
more easily decide to get rid of that structure.

Also Daixtrose's description of functionality through extern 
template functors gives an orthogonal, easy-to-maintain and
easy-to-extend code base: (new features == new code) and not
(new feature == change all the code You have)

Another advantage of this approach is that switching behaviour 
may be achieved by including/excluding (maybe only partially) of 
header files containg the functors, so pay-only-for-what-You-need
is easier achieved here.

Your operation representations store the operator as an object 
([...] class Binary { [...] operator_t const my_op; [...])
which is unneccessary and AFAICS yields a larger memory footprint
of the expression objects, which may also have effect on the 
runtime performance - at least with some compilers.

During a first study of Your code I could not find out
whether You can switch between value and reference semantics
for the expression leaves and I could not find any 
disambiguation mechanism that would allow different groups of
classes to rely on the same ET code base in the same 
translation unit. Did I miss it?

> It features a forward automatic differentiation type as an example.

I will take a glance at those.
Can You tell me which files contain the automatic diff stuff? 

Markus