Re: [boost] MPL Experiences

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-05 11:43:11

From: "Iain K.Hanson" <iain.hanson_at_[hidden]>

> > -----Original Message-----
> > From: boost-bounces_at_[hidden]
> > [mailto:boost-bounces_at_[hidden]]On Behalf Of David Abrahams
> > Sent: 05 September 2002 15:13
> >
> > The paper isn't supposed to be a reference manual. What would
> > you like to
> > see it cover?
> >
>
> Unfortunately, it is the closest thing we have to a user guide and I
suspect
> many thought that it would form the basis of a user guide. I presume that
> this was not necessarily the original intent.

Right.

> I'd be interested to know what your intended target audience was?

Attendees of a generic programming workshop.

> Going from
> the hello world of metaprogramming of factorial through to fold, bind,
and
> the fsm in approx 39 pages sure covers a lot of ground.

Yes.

> As someone who has read both C&E and MC++D but is by no stretch of the
> imagination a fluent meta programmer, I found the first part of the paper
> very easy to understand. But some of the techniques used in the more
> advanced examples defy me. Primarily, specialising templates with a
> different number of parameters than the in definition ( both more and
less
> parameters )

That's standard C++:

// unspecialized
template <class T>
struct foo_traits;

// partial specialization for pairs
template <class T, class U>
struct foo_traits<std::pair<T,U> > { ... };

> which I think is what is meant in the paper by polymorphic
> behaviour and type template parameters.

No, that's just about whether different compile-time entities (things that
can be template parameters, e.g. types, integer constants, templates) can
be manipulated by the same template code. They can't. Types are the
most-flexible among these (they can wrap the others), so if you want to
build library components once, you'll manipulate types.

> I appreciate that I am deficient in
> my knowledge of C++ but I have not seen a discussion of this technique
and
> what it means anywhere.

I don't thikn we're talking about a technique.

> On a more general note, the section on lambda is very short and it would
be
> nice to know which facilities of boost::lambda have been implemented
>  compare and contrast ).

Heh, it's similar in intent but completely different otherwise due to the
difference between compile-time and runtime code. There would be almost no
facilities in common.

> A reference to the boost::lambda documentation
>  which is very well written IMHO ) would also not go amiss.

I guess. It's a stylistic inspiration, but I don't see how it would help
anyone to learn MPL.

> Finally, the fsm example is declared as:
>
> class player : state_machine< player >
>
> I like to know what state_machine< player >  brings to the party? I.e.
could
> the code for this be included.

I'll leave this to Aleksey.

> Irrespective of whether you make any changes to refelect these comments,
I
> found it a very good paper and I learnt a lot from it. Many thanks to you
> both.

You're welcome.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com