On Wed, Mar 26, 2008 at 1:36 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG

Robert Dailey wrote:
> The term 'inherit' here does not refer to class inheritance obviously.
> It's an unusual usage of the term to me. When you do
> inherit<empty_base, WalkPacket> what exactly is that doing?

template<class T1, class T2>
struct inherit : T1, T2 {};

> Is it joining them in a list container or something? What is the
> resulting type of mpl::inherit_linearly::type? Is the result of
> mpl::inherit_linearly::type implicitly constructible from an
> mpl::transform::type?

The result of the inherit_linearly call inherits using multiple
inheritence from
all the types in the sequence.

> I'm going to read over the docs a few more times in the meantime to
> see if I can grasp this concept. Also, I'm not seeing how you're
> filling in the 2 placeholders in the signal_holder typedef.

mpl::inherit_linearly treats the second argument as a binary lambda
expression.
It is very similar to the runtime std::accumulate.  Think of inherit<_,
_> as
the MPL equivalent of a function object that returns inherit<T1, T2> for
arguments T1 and T2.

> Also, mpl::vector has a max size limit I'm sure. Right now we have a
> very minimal set of packet types, but in the future we have to
> consider the possibility that 100+ packet types will exist (the final
> number is ultimately unknown). If this is true, I doubt mpl::vector
> would be usable anymore since 100 seems too large for it. This makes
> me feel like I'm going to have to resort to a completely template-less
> approach. I might have to send a generic Packet object to all
> subscribers, which has a ::Get() method that performs a
> static_cast<>() to the concrete type based on an ID.

MPL allows configuration to make vector able to hold larger numbers of
types.
If you need such a large number of Packets, compilation may be very slow
with metaprogramming.

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).

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.

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.

4) So mpl::inherit_linearly::type is the very base type in the inheritance chain? Does this allow us to access any type simply by performing up-casts? 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?

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

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.

7) The explanation you provided (quoted below) makes no sense to me. Could you be so kind as to emphasize a little more? Keep in mind that I have no experience with std::accumulate.

mpl::inherit_linearly treats the second argument as a binary lambda
expression.
It is very similar to the runtime std::accumulate.  Think of inherit<_,
_> as
the MPL equivalent of a function object that returns inherit<T1, T2> for
arguments T1 and T2.

Again, thanks for your help and I'm sorry for being so slow. The MPL library has always proven to be frustrating for me to learn. I do appreciate you helping me out with it though. Perhaps my inexperience with MPL is why I have such a difficult time figuring out designs for some of these issues on my own.