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