Re: [Boost-users] Need boost's help with poor design

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-03-26 17:37:09

AMDG

Robert Dailey wrote:
> It's good to know that mpl::vector can be configured, however the slow 
> compilation time will require me to ensure that the mpl::vector 
> remains in an implementation file as to not affect the compile time of 
> other files (I'm assuming this is the solution).
>
> At this point I think the very last thing I need is to understand the 
> inherit concepts. I'm still really confused about how they work. In 
> both the doxygen documentation for inherit_linearly and in your 
> examples, I do not see anyone explicitly filling in the '_' arguments. 
> However, the boost examples use _1 and _2 which makes it even more 
> confusing. I'll outline the very specific questions I have:
>
> 1) I've never used the _ placeholder, so I'm not really sure how it 
> works. How is it different from _1, _2, etc. Right now I'm familiar 
> with using Boost.Bind with the _1 concepts, how would _ be used in 
> boost.bind (just as an example so I can see the differences).
_ is just syntactic sugar.  mpl::inherit<_1, _2> would work just as well.
The first occurrence of _ is equivalent to _1
The second occurrence of _ is equivalent to _2.
The third occurence of _ is equivalent to _3

> 2) What is the purpose in how mpl::inherit forms its classes? You say 
> it does "class inherit : T1, T2", however I do not see the benefit in 
> this.

The ultimate result is a struct that behaves like:

struct signal_holder :
    boost::signal<void(WalkPacket const&)>
    boost::signal<void(ChatPacket const&)>,
    boost::signal<void(QuestPacket const&)>
   ...
{};

This holds instances of each of the boost::signal types
and allows access by upcasting.

>
> 3) I understand that mpl::inherit_linearly treats the second template 
> parameter as a binary lambda as you explained, however I was expecting 
> to see that we explicitly fill in the placeholders, and that's the 
> part that's throwing me off. I don't see how the placeholders are 
> being filled.

We don't fill in the placeholders.  mpl::inherit_linearly does.

>
> 4) So mpl::inherit_linearly::type is the very base type in the 
> inheritance chain?

mpl::inherit_linearly::type is derived from all the types in the sequence.
it is not a base class of anything. 
> Does this allow us to access any type simply by performing up-casts?
Yes.
> It looks like from the boost docs that the up-cast is performed by 
> assigning the mpl::inherit_linearly::type directly to the type you 
> want, is this correct?
Yes.  Or as in my example code, you can cast to a reference to the type 
you want.

> 5) Can you give an example of what this inheritance tree looks like 
> generated by mpl::inherit_linearly?

empty_base   signal<void(WalkPacket)>
    |               |
    +---------------+
                    |
               inherit<...>   signal<void(ChatPacket)>
                    |              |
                    +--------------+
                                   |
                               inherit<...>   signal<void(QuestPacket)>
                                   |              |
                                   +--------------+
                                                  |
                                              inherit<...>

> 6) Can you give me a small [pseudo]code example of what 
> mpl::inherit_linearly does for each object in the list specified at 
> the first template parameter? The way it internally works conceptually 
> is unknown to me.

type mpl::inherit_linearly(typelist l, lambda_expression f, type base = 
empty_base) {
    type result = base;
    for each x in l {
        result = mpl::apply(f, result, x);
    }
    return(result);
}

mpl::apply does the magic of substituting for placeholders.

In Christ,
Steven Watanabe