
Generic programming is fairly well understood. Concepts define requirements, types model concepts, generic code manipulates models via valid expressions for that concept, etc. Also pretty well understood is how to define customization points so that arbitrary types can be made to model a concept non-intrusively. But these techniques seem to break down for object construction. Consider: template< class Inner > struct facade { facade( /* what here? */ ) : inner_( /* and what here? */ ) {} private: Inner inner_; }; How does facade know how to initialize inner_? The answer affects how facade itself should be initialized. One possibility is that facade defines N constructors that take up to N arguments, and just forwards them to inner_. That might work in this narrow case, but what if facade has 2 inner objects of different types? How should constructor arguments get dispatched to the different sub-objects? In general, facade has no way of knowing. Is this a problem others have run into? What sorts of techniques are people using? I have come up with a little generic object construction utility using Boost.Parameter that works for me. It allows you to non-intrusively associate named parameters with a type for the purpose of construction, and a way to forward a (possibly filtered) argument pack on to sub-objects. Is there general interest in such a utility? -- Eric Niebler Boost Consulting www.boost-consulting.com

This sounds very interesting. I did like to try this out. Chris On 9/25/06, Eric Niebler <eric@boost-consulting.com> wrote:
Generic programming is fairly well understood. Concepts define requirements, types model concepts, generic code manipulates models via valid expressions for that concept, etc. Also pretty well understood is how to define customization points so that arbitrary types can be made to model a concept non-intrusively.
But these techniques seem to break down for object construction. Consider:
template< class Inner > struct facade { facade( /* what here? */ ) : inner_( /* and what here? */ ) {} private: Inner inner_; };
How does facade know how to initialize inner_? The answer affects how facade itself should be initialized.
One possibility is that facade defines N constructors that take up to N arguments, and just forwards them to inner_. That might work in this narrow case, but what if facade has 2 inner objects of different types? How should constructor arguments get dispatched to the different sub-objects? In general, facade has no way of knowing. Is this a problem others have run into? What sorts of techniques are people using?
I have come up with a little generic object construction utility using Boost.Parameter that works for me. It allows you to non-intrusively associate named parameters with a type for the purpose of construction, and a way to forward a (possibly filtered) argument pack on to sub-objects. Is there general interest in such a utility?
-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 09/25/2006 01:00 PM, Eric Niebler wrote:
Generic programming is fairly well understood. Concepts define requirements, types model concepts, generic code manipulates models via valid expressions for that concept, etc. Also pretty well understood is how to define customization points so that arbitrary types can be made to model a concept non-intrusively.
But these techniques seem to break down for object construction. Consider:
template< class Inner > struct facade { facade( /* what here? */ ) : inner_( /* and what here? */ ) {} private: Inner inner_; };
How does facade know how to initialize inner_? The answer affects how facade itself should be initialized.
One possibility is that facade defines N constructors that take up to N arguments, and just forwards them to inner_. That might work in this narrow case, but what if facade has 2 inner objects of different types? How should constructor arguments get dispatched to the different sub-objects? In general, facade has no way of knowing. Is this a problem others have run into? What sorts of techniques are people using?
AFAICT, This similar to the problem I ran into with the array extension to Andy Little's fusion matrix. Andy wanted the ability to initialize with something like: maxtrix<...whatever...> a_matrix ( a0_0, a0_1, ... , a0_m , a1_0, a1_1, ... , a1_m ... , an_0, an_1, ... , an_m ) However, with the array extension (see <boost-vault>/Template Metaprogramming/array.zip) I had to have something like that shown here: http://archives.free.net.ph/message/20060917.155443.96aa800a.en.html What I needed was something that would emulate the way structs c or c++ are intialized (with nested {}'s). IOW, instead of requiring all the typedefs for the rank*_type's, there would be someway to emulate: matrix<...whatever...> a_matrix { { a0_0, a0_1, ... , a0_m} . { a1_0, a1_1, ... , a1_m} ... , { an_0, an_1, ... , an_m} } My first guess as to how to do it would be to somehow use BOOST_PP nested sequences passed to some new macro which would reformat it into something like what was shown in the 96aa800a.en.html post mentioned above.
I have come up with a little generic object construction utility using Boost.Parameter that works for me. It allows you to non-intrusively associate named parameters with a type for the purpose of construction, and a way to forward a (possibly filtered) argument pack on to sub-objects. Is there general interest in such a utility?
Yes. I'd like to see how this is done. In particular, I like to see if it would help with the array problem mentioned above.

Yes. I'd like to see how this is done. In particular, I like to see if it would help with the array problem mentioned above. Also, there's another instance where I might find this useful. The tuple (either the current one or fusion's tuple, or maybe both) have 1-n templated CTOR's where the i-th such CTOR intializes the 1st i elements in the tuple. However, the j-th arg in this i-th CTOR (where j<=i) must be a type acceptable to the type_j, where type_j is type of the j-th tuple element. IIUC, you're code might enable
On 09/25/2006 01:53 PM, Larry Evans wrote: [snip] passing more than just 1 arg to the type_j-th CTOR. Is that right?

"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:ef98no$58f$1@sea.gmane.org...
AFAICT, This similar to the problem I ran into with the array extension to Andy Little's fusion matrix. Andy wanted the ability to initialize with something like:
maxtrix<...whatever...> a_matrix ( a0_0, a0_1, ... , a0_m , a1_0, a1_1, ... , a1_m ... , an_0, an_1, ... , an_m )
Actually I think what I want is more like : matrix<..> ( view_sequence<Function1<seq1,seq1a>, Function2<...>, Function3<...>, Function4<...>....>() ); where typically these functions store the dot_product info for each element. The function args may be references to the two input matrices in a multiply or just the particular row and column they need for their dot product. regards Andy Little

"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:ef9lkt$k1l$1@sea.gmane.org...
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:ef98no$58f$1@sea.gmane.org...
AFAICT, This similar to the problem I ran into with the array extension to Andy Little's fusion matrix. Andy wanted the ability to initialize with something like:
maxtrix<...whatever...> a_matrix ( a0_0, a0_1, ... , a0_m , a1_0, a1_1, ... , a1_m ... , an_0, an_1, ... , an_m )
Actually I think what I want is more like :
matrix<..> ( view_sequence<Function1<seq1,seq1a>, Function2<...>, Function3<...>, Function4<...>....>() );
In fact this should probably be: matrix<...> m1; matrix<...> m2; matrix<...> (view_sequence<Function1<M1,M2>, Function2<M1,M2>, Function3<M1,M2.>,...> >(m1,m2) ); regards Andy Little

"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:ef9m9h$lqg$1@sea.gmane.org...
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:ef9lkt$k1l$1@sea.gmane.org...
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:ef98no$58f$1@sea.gmane.org...
AFAICT, This similar to the problem I ran into with the array extension to Andy Little's fusion matrix. Andy wanted the ability to initialize with something like:
maxtrix<...whatever...> a_matrix ( a0_0, a0_1, ... , a0_m , a1_0, a1_1, ... , a1_m ... , an_0, an_1, ... , an_m )
Actually I think what I want is more like :
matrix<..> ( view_sequence<Function1<seq1,seq1a>, Function2<...>, Function3<...>, Function4<...>....>() );
In fact this should probably be:
matrix<...> m1; matrix<...> m2; matrix<...> (view_sequence<Function1<M1,M2>, Function2<M1,M2>, Function3<M1,M2.>,...> >(m1,m2) );
Question is, is that the same as transform_view?, but I don't think it is. transform_view is: view_sequence<F<at<M1,1>,at<M2,1> > ,F<at<M1,2>,.at<M2,2> >,...> etc. IOW each function gets to see only its elements, not the whole input sequence. I think that is a difference regards Andy Little

Eric Niebler wrote:
I have come up with a little generic object construction utility using Boost.Parameter that works for me. It allows you to non-intrusively associate named parameters with a type for the purpose of construction, and a way to forward a (possibly filtered) argument pack on to sub-objects. Is there general interest in such a utility?
I'm interested. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

"Eric Niebler" <eric@boost-consulting.com> writes:
One possibility is that facade defines N constructors that take up to N arguments, and just forwards them to inner_. That might work in this narrow case, but what if facade has 2 inner objects of different types? How should constructor arguments get dispatched to the different sub-objects? In general, facade has no way of knowing. Is this a problem others have run into? What sorts of techniques are people using?
Czarnecki and Eisenecker (I think) pioneered the use of tuples for this purpose.
I have come up with a little generic object construction utility using Boost.Parameter that works for me. It allows you to non-intrusively associate named parameters with a type for the purpose of construction, and a way to forward a (possibly filtered) argument pack on to sub-objects. Is there general interest in such a utility?
Neat idea; it's nice to have the by-name interface here. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Andy Little
-
Chris Weed
-
David Abrahams
-
Eric Niebler
-
Joel de Guzman
-
Larry Evans