Boost logo

Boost Users :

Subject: Re: [Boost-users] MPL: Lazy Evaluation and Nullary Metafunction
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-10-16 17:29:58


Missing Rainbow wrote:
> I am reading about the lazy evaluation and nullary metafunction in the
> MPL book. While discussing the lazy evaluation technique the
> following code is presented (page 57):
> struct add_pointer_f
> {
> template <class T>
> struct apply : boost::add_pointer<T> {};
> };
> typedef mpl::vector<int, char*, double&> seq;
> typedef mpl::transform<seq, boost::add_pointer<_> > calc_ptr_seq;
> The point of the above code was to demonstrate that the nullary
> metafunction calc_ptr_seq represents the sequence "int*, char**,
> double&*", even though the last element in that sequence is not valid.
> Thanks to lazy evaluation. As long as we don't access the third
> element in the sequence represented by calc_ptr_seq, everything should
> work fine. Is my understanding correct?

Not quite. transform is greedy. When you access calc_ptr_seq::type,
all the elements will be computed immediately. The point is that
if you don't access the ::type, transform will not be instantiated at all.

Actually, this example makes no sense to me.
boost::add_pointer is smart. For example, while double&* is
illegal, boost::add_pointer<double&>::type is double*.

It looks like the example was originally:

struct add_pointer_f
    template<class T>
    struct apply
        typedef T* type;
typedef mpl::vector<int, char*, double&> seq;
typedef mpl::transform<seq, add_pointer_f> calc_ptr_seq;

and was partially refactored.

> Also, other than nullary metafunction, is there any other approach to
> lazy evaluation? Or will lazy evaluation _always_ be implemented with
> the help of nullary metafunction?

Well, there are other ways to achieve the same effect, but in MPL,
if you have a metafunction that you want to evaluate lazily, you will
always do so by leaving off the type. This of course yields a nullary

In Christ,
Steven Watanabe

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at