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

On Wed, Mar 26, 2008 at 4:37 PM, Steven Watanabe 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 boost::signal, boost::signal ... {};

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 | | +---------------+ | inherit<...> signal | | +--------------+ | inherit<...> signal | | +--------------+ | 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.