Re: [boost] Library design Q : overloads v/s default args

Subject: Re: [boost] Library design Q : overloads v/s default args
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-06-20 12:46:16

David Abrahams wrote:
> I'm just curious, Have you thought about using const rvalues as return
> types in these situations?  If you consider the adapter itself to be
> immutable and the target sequence to be a separate object (which in
> reality it is), it actually all makes sense.  And a T const return
> type will bind nicely to a generalized U& argument.

It's unbelievable, this really works.

I had first deactivated the "perfect forwarding" code generation and tried to reproduce the compile errors. This proved quite tricky, as MSVC seems to have no problems binding temporaries against lvalue references (I don't know whether the deduced type will be const or not) , but gcc-4.4 and gcc-4.5 failed to compile as expected. Then I changed the return types from the wrappers to "T const" and gcc-4.4 and gcc-4.5 no longer failed to compile.

So now I will have to post an update to the ublas mailing list...

> Boost.Parameter does a very good approximation of perfect forwarding,
> generating T&/T const& parameters for all out- and in/out- parameters.
> It does erase rvalue-ness, but that's pretty much a given with C++03
> that AFAICT nobody knows how to avoid.

In fact, Rutgers code doesn't erase rvalue-ness as well, it was just me misinterpreting things. So what he does is really just a "perfect forwarding" emulation, just as Boost.Parameter does. However, I wonder whether Boost.Parameter uses the preprocessor to implicitly generate a similar amount of code as Rutgers solution explicitly generates. In that case, I would wonder whether it would be possible to selectively turn off the T const& overload for parameters that don't need it (so that we could still use the "workaround" mentioned above).

Thanks again.

Regards,
Thomas