Re: [boost] typelists: MPL tutorial + partial review

From: David A. Greene (greened_at_[hidden])
Date: 2001-12-13 16:24:16

Aleksey Gurtovoy wrote:

> users :). On the other hand, simpler implementation would eliminate all
> these cool binders, composers and loops :).. 

This is _good_!  Not that loops, binders etc. aren't used but
that there is an opportunity in a tutorial to mention that
they don't _have_ to be used and it is sometimes better _not_ to
use them.  Many new C++ programmers get tripped up trying to
use every whiz-bang feature of the language.  Ditto the STL.
I think the same problems may crop up with MPL.

> hmm, seems like there is a need for a sequel tutorial :).

Please!  :)

> 'for_each' name is an artifact of the previous versions of MPL which had
> "real", STL-like 'for_each', i.e. the one that took "generative" function
> class with state. The approach has proved impractical, and in the version
> you work with 'for_each' has been assigned the semantics of 'accumulate',
> but without a name change - which obviously was a mistake. In the most
> recent revision of the library (which I haven't checked into CVS yet)
> 'accumulate' and 'for_each' are synonyms, and the latter is deprecated (we
> have some code that needs to be rewritten before I can remove it).

Yes!  This would have gone a long way to clearing up my
confusion about the example.

> In the boost::mpl documentation these are called "function classes" (by
> analogy with function objects), as opposite to (I hope) self-explanatory
> "class template metafunctions" (both of the concepts are particular
> instances of more general "metafunction" concept).

This makes more sense to me as a C++ programmer than bringing
in syntax and semantics of a language I rarely deal with.

>>3.2 MPL GenScatterHierarchy Implementation
>>
> This is one particular example that I would implement differently. Dave have
> already posted an example of implementation that is very close to what I am
> thinking of, but for the sake of demonstration of what I think is a "native
> MPL solution" :), here is my code:

Aha!  Much clearer, thanks.  It still took a bit of study to
wrap my head around it.  Specifying the I/O of metafunctions
passed to derived_class_generator/accumulate would help.

>>4.2 Fields Implementation

> Again, this is something that I would implement differently:

Slick.  :)  Again, I don't understand it completely, but I
appreciate its greater simplicity.  I feel like I have a
_chance_ to understand it completely now.  Thanks!

                       -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson