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