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

From: Robert Dailey (rcdailey_at_[hidden])
Date: 2008-03-26 15:34:09

On Wed, Mar 26, 2008 at 1:36 PM, Steven Watanabe <watanabesj_at_[hidden]>
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.