Re: Understanding MPL

From: Paul Mensonides (yg-boost-users_at_[hidden])
Date: 2003-04-17 20:23:20

David Abrahams wrote:
>> This is flat out not true.  The general user understands that macros
>> are relatively simple textual expansions.  The general user does not
>> understand the details of macro expansion, and these details are
>> extremely important for any effective use of the preprocessor
>> metaprogramming.
>
> That is flat out not true.  I have made some effective use of PP
> metaprogramming without understanding the details of macro expansion.

But you also, to a degree, understand the problems associated with the types of
things that you have done with the pp-lib.  Your understanding of it may not be
as extensive as mine, but it is certainly greater than the average user.

BTW, I'm not disagreeing that a sort of "synopsis" needs to exist; I'm just
dubious of how helpful it will be in flattening the learning curve.

>> Preprocessor metaprogramming and, to a large extent, template
>> metaprogramming is all about manipulating/exploiting the "details"
>> of their respective parts of the language.  I absolutely guarantee
>> that this level of understanding does not generally exist--for
>> template metaprogramming and especially for preprocessor
>> metaprogramming.
>
> In general libraries like MPL/Type Traits and Boost PP allow users to
> ignore (or actually be ignorant of) many of those "details" and
> concentrate on the task at hand.  That's in part what makes them so
> powerful.

Yes.

>>> The general user does not understand the areas of functionality in
>>> the Boost pp-lib, what they are and how they may be used, because
>>> there is no good organizational explanation about the various areas
>>> in which the Boost pp-lib can be effectively used to accomplish
>>> either template programming goals or just useful code generation
>>> goals.
>>
>> Both and more.  As I said in the post I just sent a few minutes ago,
>> I will address this this weekend.  I'll try to write up a decent
>> overview of the functionality available and send it to you so you
>> can tell me what
>> you think.
>
> Is it done yet?  Can I see?

I started it.  I got through CAT, STRINGIZE, WSTRINGIZE, EXPAND, EMPTY, and
IDENTITY, but then I realized that I was already well over 1000 words.  At that
pace, I don't have time to deal with it immediately, so I either have to deal
with it later, or rethink my "strategy."

>> However, there is no getting around the complexity involved because
>> Cpp works against encapsulation.
>
> Do you mean for example the leaking of information like recursion
> levels and different recursion mechanisms into the library interface?
> If so, I think that stuff is graspable without having to understand
> the reasons for it.  You can just give people rules to follow and be
> done with it.

Only to a point.  User code has to deal with this issue also.  For instance, the
reasons why things like is are unsafe:

#define USER_A(n) class BOOST_PP_CAT(T, n)
#define USER_B(n) BOOST_PP_CAT(T, n)

#define MACRO(x) \
    BOOST_PP_CAT( \
        USER_, \
        BOOST_PP_IF(x, A, B)(1) \
    ) \
    /**/

> What you haven't done is to write something like, "C and C++ code
> (especially library code) often contains lots of boilerplate
> repetition, leading to fragile systems that are tedious to write and
> maintain.  The Boost PP lib provides a programmatic framework for code
> generation which can be used to eliminate repeated boilerplate and
> factor out common textual patterns in code."
> ...and take it from there.

Do mean a sort of "descriptive table of contents"?

>>> As an example, I understand that there is part of the Boost pp-lib
>>> which deals with easing the specification of repetitive constructs.
>>> That could be discussed, macros which solve repetitive generation
>>> problems can be discussed and explained, and the general user will
>>> now have an idea of what macros in the pp-lib help with repetitive
>>> programming problems and how a given macro may be used in that way.
>>
>> As I've said before, this categorization is already there:
>> docs/headers/repetition/* I agree that this organization is not
>> explicit, but it is there for anybody who cares to look deeply at
>> it.
>
> The problem is that a general sense of the library and its
> capabilities should be possible without looking deeply.

What I'm stuck on is this....  There is a big difference between "a general
sense of the library and its capabilities" and "a sense of how to use the
library effectively."  Are you referring to the former or the latter?  The
former is easy, the latter is not.

>>> You may be right that the general user must first attempt to master
>>> the arcana of macro expansion and what does and does not work many
>>> macros attempt to expand inner macros in different situations in
>>> order to even use the pp-lib at all.
>>
>> This is definitely part of it, but it has more to do with the
>> vertical dependencies associated with the implementation of each
>> primitive in the library.  How primitive X is implemented is a
>> direct concern to primitive Y.  Expansion order is a significant
>> factor as well.  Encapsulation is a huge issue that causes use of
>> the library to be closely tied to the implementation of the library.
>> I have spent an excessive amount of time attempting to minimize
>> these dependancies.
>
> And you did a good job, which means that most users don't need to
> worry about it.

It means that most users don't have to worry about it with *certain constructs*,
but not in general.

Regards,
Paul Mensonides