There are essentially two areas where expression templates [13,6] and views are related. These are:
It would be nice to be able to write the transformation for a
transform_view, or the filter predicate for a filter_view,
using an expression template. Unfortunately, expression templates
bind up the information about the expression into the type itself,
thereby forcing the transformation template parameter being declared
in a transform_view to match it. This requires the user of the
expression template library to understand the internals of how the
expression template will be built. This is nearly as bad as having to
know the name mangling method of the compiler. There is work being
done in this area but at the moment it appears that when the compiler
creates the expression template the type information is used and then
lost. So for the moment this is not a satisfactory way of building the
functors.
On the contrary, using expression templates directly to provide the functionality instead of using views is possible. But it puts the burden on the user side of the interface: Since expression templates are built locally and thrown away after use, they must be defined at the point of use. Thus the user of an interface must know the details of the underlying container's elements. On the other hand, smart iterators and views provide a clean interface to the user without exposing the internals of the underlying container.