On 08/30/2006 04:27 PM, Paul Mensonides wrote:
-----Original Message----- [snip]
I see that you updated your library! A couple of quick notes...
1) Because the macro names are uppercased (annoying, but necessary), [snip]
2) The #error directive on line 18 has an unmatched double-quote. [snip]
Thanks, Paul. I've updated the vault with the hopefully corrected code.
Regarding what the generated code is doing (as opposed to what the generator code is doing), the major problem with forwarding without language support is that it is a combinatorial problem--rather than linear. I.e. you really need various combinations of const and-or [snip]
Ouch! Do you know of anyone working on a compiler to solve this forwarding problem?
In any case, it is still reasonable up to 5 parameters if you're ignoring volatile. I know that Dave implemented this kind of forwarding for an operator new workalike that returned a smart pointer. (With perfect forwarding, you can design a reference-counted smart pointer so that it doesn't require a double allocation.)
I assume you mean one which doesn't use an intrusive refcount, IOW, uses a "detached" refcount like the existing shared_ptr? IOW, with the current shared_ptr, an one allocation is for the pointed-to object, the other is for the refcount. If so, then this is what I was trying to do with: http://tinyurl.com/obnls However, instead of using: template < class T0 , class T1 , ... , class Tn > ctor_this_type ( T0 a0 , T1 a1 , ... , Tn an ) : ctor_base_type ( a0 , a1 , ... , an ) {} the workaround implemented with the help of managed_ptr_ctor_forwarder.hpp: http://tinyurl.com/o7zlg generates CTOR's of the form: template < class VecOfTypes > ctor_this_type ( VecOfTypes const& , mpl::at_c<VecOfTypes,0>::type a0 , mpl::at_c<VecOfTypes,1>::type a1 , ... , mpl::at_c<VecOfTypes,n>::type an ) : ctor_base_type ( a0 , a1 , ... , an ) {} IOW, the client has to specify the "signature" of the ctor_base_type CTOR via a single VecOfTypes template arg to the ctor_this_type CTOR. The justification for this was that the client would have to know which ctor_base_type CTOR he wanted anyway, so it would not be that much of a burden for him to name it, indirectly, by supplying the "signature". I've uploaded prototype code demonstrating the idea to the same vault directory, in file typelist_fwding.cpp. -regards, Larry