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

From: Robert Dailey (rcdailey_at_[hidden])
Date: 2008-03-26 18:57:51

On Wed, Mar 26, 2008 at 4:37 PM, Steven Watanabe <watanabesj_at_[hidden]>
wrote:

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

After investigating this a little more (plus from the answers you provided
above) I think I fully understand the problem. My only concern at this point
is compile time, as you pointed out. For 100 packet types, do you think
compile time would be noticeably affected (assuming that all of the boost
includes are in a precompiled header file)? How about for 1000 packet types?

Thanks so much for your help, you definitely provided me a great design.
Perhaps in the future I'll be able to generate great designs like this since
now I have learned a lot more about the mpl library.