Re: [boost] [preprocessor]undef file iteration include guard?

From: Larry Evans (cppljevans_at_[hidden])
Date: 2006-08-31 13:24:00

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