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

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-01 06:39:19

"Paul Mensonides" <pmenso57_at_[hidden]> writes:

>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Larry Evans
>
>> > 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?
>
> I know this is one of the things being tossed around in the committee, but I
> don't know the likelihood that of acceptance or if it has already been accepted.
> Dave would know more.

It's solved by rvalue references, which, IIRC, are in a late stage of
review for inclusion into the next standard.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2027.html

> One problem of forwarding is arity (which can be more-or-less solved with code
> generation).  The more stubborn problem with forwarding is temporaries.  They
> cannot be bound to a non-const reference, and the template mechanism cannot
> deduce T as const U in a parameter of type T&.  OTOH, non-temporaries don't have
> any problem deducing T as U or const U in a parameter of type T&.
> Unfortunately, the only way to handle it transparently is to overload via
> cv-qualifier--which leads the the combinatorial explosion when multiple
> parameters are involved.

Strictly speaking, it's not even transparent if you use the
combinatorial explosion because you lose rvalue-ness, which is
detectable today (at least for mutable rvalues, which are the ones
that usually matter).  You will also probably force the compiler to
make more copies than it would if you were passing parameters by value
in some cases, which is sorta the same issue.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com