«

The implemntation of a tempate function e.g.:

tamplate<typename A, typename B, typename C>
fun( A&& a, B&& b, C&& c)

has chance to take advantage that some paramters are passed as a rvalue refernce.
Then for these parameters the move semantic can be used instead of potentialy expensive object coping.


But what about a non-template function? Using overloads I have to write 8 different function declartations for 3-parameters function
(for n-params function => 2^n)
Why authors of rvalue reference concepts have not decided to extend perfect forwarding for non-template functions.
Of cource it is not obvious how it could be implemented neigher if it is generally possible.
But after couple of hours I realized that it is possible and the implemntation is quite inexpensive and nice.

Below it is my proposition. In order for a function to take parameters both as a lvalue or rvalue reference
the new type specyficator &^ should be definde. The function signature will look like:

fun( A&^, B&^, C^& )

One signature and one implemntation. Now consider the body and parameter usage.

fun( A&^ a, B^& b, C^& c ) {

f(a); // 'a' as lvalue reference
a = A(); // 'a' as lvalue reference
g( std::move(b) ); // 'b' as rvalue reference
gun( ^a, ^b, c ); // 'a' 'b' as original reference or copy, 'c' as lvalue reference or copy
}

In the last line the new prefix operator '^' (restore reference operator) occured that dinamically restores original reference kind.

The key fact of rvalue reference is that using 'a', 'b', 'c' is always defaultly as lvalue reference (first three lines of 'fun').
So compilator does not have to generate different codes. Techniacally lvalue and rvalue reference are the same thing.
The only difference is during called function signature matching from overloaded list. But it is being done during compilation time.
In the example the place afected by the kind of passed parameter reference is only during calling 'gun'.
Of course the decision can not be done during compilation time. So compilator should generate a swich respecting all possibilities.
The kind of reference for all parameters can be stored as an additional hidden parameter (like this)
of type uintptr_t treated as a bit vector.

Has the switch to be expensive? I think that has not! I suspect that it won't be more expensive that virtual method call.
If 'gun' has only one signature than there is no switch. But consider the following 'gun' signatures:

gun( A&^, const B&, C c )
gun( A&^, B&&, C c )

For these overloads comilator generates only two variants of switch in 'fun'. For parameter 'a' just generates copy operation for the bit of reference kind.
The last thing is that 'gun' singatures have match to all possible variant calls from 'fun' in order for no unmatch errors to occur in runtime.
And this can be simply check in compilation time.

Isn't it a natural next evolution step for rvalue reference concept?

On 28/06/2012 11:17, dervih wrote:
> The implemntation of a tempate function e.g.:
>
> tamplate<typename A, typename B, typename C>
> fun( A&& a, B&& b, C&& c)
>
> has chance to take advantage that some paramters are passed as a rvalue refernce.
> Then for these parameters the move semantic can be used instead of potentialy expensive object coping.
>
>
> But what about a non-template function? Using overloads I have to write 8 different function declartations for 3-parameters function
> (for n-params function => 2^n)
> Why authors of rvalue reference concepts have not decided to extend perfect forwarding for non-template functions.
> Of cource it is not obvious how it could be implemented neigher if it is generally possible.
> But after couple of hours I realized that it is possible and the implemntation is quite inexpensive and nice.
>
> Below it is my proposition. In order for a function to take parameters both as a lvalue or rvalue reference
> the new type specyficator &^ should be definde. The function signature will look like:
>
> fun( A&^, B&^, C^& )
>
> One signature and one implemntation. Now consider the body and parameter usage.
>
> fun( A&^ a, B^& b, C^& c ) {
>
> f(a); // 'a' as lvalue reference
> a = A(); // 'a' as lvalue reference
> g( std::move(b) ); // 'b' as rvalue reference
> gun( ^a, ^b, c ); // 'a' 'b' as original reference or copy, 'c' as lvalue reference or copy
> }
>
> In the last line the new prefix operator '^' (restore reference operator) occured that dinamically restores original reference kind.

I think that the above proposal is superfluous. Why cannot you already
use the original template function and std::forward<T>() to do
perfect-forwarding?

Am Donnerstag, 28. Juni 2012 11:17:12 UTC+2 schrieb dervih:
> [...]
> But what about a non-template function? Using overloads I have to write
> 8 different function declartations for 3-parameters function
> (for n-params function => 2^n)
> Why authors of rvalue reference concepts have not decided to extend
> perfect forwarding for non-template functions.
> Of cource it is not obvious how it could be implemented neigher
> if it is generally possible.
> But after couple of hours I realized that it is possible and
> the implemntation is quite inexpensive and nice.
>
> Below it is my proposition. In order for a function to take parameters
> both as a lvalue or rvalue reference
> the new type specyficator &amp;^ should be definde. The function
> signature will look like:
>
> fun( A&^, B&^, C^& )
>
> One signature and one implemntation. Now consider the body and
> parameter usage.
>
> fun( A&amp;^ a, B^&amp; b, C^&amp; c ) {

[plain a, b, c are lvalues]

> gun( ^a, ^b, c ); // a b as original reference or copy,
> // c as lvalue reference or copy
> }
>
> In the last line the new prefix operator ^ (restore reference operator)
> occured that dinamically restores original reference kind.

> [...]
> Of course the decision can not be done during compilation time. So
> compilator should generate a swich respecting all possibilities.

What about the possibilities that don't work? For example, in case there isno overload of gun which accepts an rvalue as first parameter? Should thisgenerate an exception?

Also, I can imagine that generating calls to all possible overloads might trigger a lot of template instantiations (consider gun to be a function template) which could trigger compilation errors because not every combination is supported/needed.

> The last thing is that gun singatures have match to all possible
> variant calls from fun in order for no unmatch errors to occur in runtime..
> And this can be simply check in compilation time.

This sort of checking is not possible at compile time (because a function declaration is not enough to see whether a call would "work" or not). But itis theoretically possible at link-time. The generation of the "invocation switch" could be deferred to link-time and only made to include the calls that are actually needed in the whole program (this would also eliminate thetemplate instantiation issue I mentioned earlier). But this approach doesn't seem to work with dynamic linking libraries unless you include runtime-compilation in the whole process. Requiring C++ implementations to do link-time code generation alone seems already too much to ask for, IMHO.

If you're worried about unnecessary code duplication you might implement 'fun' from your example like this:

void fun_impl(A& a, B& b, C& c) {
f(a);
a = A();
}

template<class T, class U>
void fun(T&& a, U&& b, C c) {
fun_impl(a,b,c);
gun(forward<T>(a),forward<U>(b),move(c));
}

or hope on the toolset to automatically detect and compensate for redundancies across different instantiations of function templates. I actually don'tknow how well compilers and linkers are able to do this kind of "code bloat reduction" on their own.

Cheers!
SG

On 2012-07-12 14:25, SG wrote:
> Am Donnerstag, 28. Juni 2012 11:17:12 UTC+2 schrieb dervih:
>> [...]
>> But what about a non-template function? Using overloads I have to write
>> 8 different function declartations for 3-parameters function
>> (for n-params function => 2^n)
>> Why authors of rvalue reference concepts have not decided to extend
>> perfect forwarding for non-template functions.
>> Of cource it is not obvious how it could be implemented neigher
>> if it is generally possible.
>> But after couple of hours I realized that it is possible and
>> the implemntation is quite inexpensive and nice.
>>
>> Below it is my proposition. In order for a function to take parameters
>> both as a lvalue or rvalue reference
>> the new type specyficator &amp;^ should be definde. The function
>> signature will look like:
>>
>> fun( A&^, B&^, C^& )
>>
>> One signature and one implemntation. Now consider the body and
>> parameter usage.
>>
>> fun( A&amp;^ a, B^&amp; b, C^&amp; c ) {
>
> [plain a, b, c are lvalues]
>
>> gun( ^a, ^b, c ); // a b as original reference or copy,
>> // c as lvalue reference or copy
>> }
>>
>> In the last line the new prefix operator ^ (restore reference operator)
>> occured that dinamically restores original reference kind.
>
>> [...]
>> Of course the decision can not be done during compilation time. So
>> compilator should generate a swich respecting all possibilities.
>
> What about the possibilities that don't work? For example, in case there is no overload of gun which accepts an rvalue as first parameter? Should this generate an exception?

All variants of gun are required for compilation and link. Generating the swich compilator places all variants of call to gun.
Therefore there is no exception in runtime.

>
> Also, I can imagine that generating calls to all possible overloads might trigger a lot of template instantiations (consider gun to be a function template) which could trigger compilation errors because not every combination is supported/needed.

Yes, but for such situation fun can be also a template function.

>
>> The last thing is that gun singatures have match to all possible
>> variant calls from fun in order for no unmatch errors to occur in runtime.
>> And this can be simply check in compilation time.
>
> This sort of checking is not possible at compile time (because a function declaration is not enough to see whether a call would "work" or not). But it is theoretically possible at link-time. The generation of the "invocation switch" could be deferred to link-time and only made to include the calls that are actually needed in the whole program (this would also eliminate the template instantiation issue I mentioned earlier). But this approach doesn't seem to work with dynamic linking libraries unless you include runtime-compilation in the whole process. Requiring C++ implementations to do link-time code generation alone seems already too much to ask for, IMHO.
>
The checking is possible. I want only that the following switch:
decltype( gun(/*no important what*/) ) r ;
switch( rr_flag ) { // rvalue reference flag
case 0x0 : r = gun( a, b, c); break;
case 0x1 : r = gun( a, std::move(b), c); break;
case 0x2 : r = gun( std::move(a), b, c); break;
case 0x3 : r = gun( std::move(a), std::move(b), c); break;
}
was automatically generated be a compilator.
Such switch does not require to see the gun's implementation rather only requires declaration.



> If you're worried about unnecessary code duplication you might implement 'fun' from your example like this:
>
> void fun_impl(A& a, B& b, C& c) {
> f(a);
> a = A();
> }
>
> template<class T, class U>
> void fun(T&& a, U&& b, C c) {
> fun_impl(a,b,c);
> gun(forward<T>(a),forward<U>(b),move(c));
> }

This is very ugly workaround, one of the problem is that some part of fun's implementation have to moved to *.h or *.inl
Morover now fun potentially accepts all parameter types.
Therefore I would like to avoid using templates.

>
> or hope on the toolset to automatically detect and compensate for redundancies across different instantiations of function templates. I actually don't know how well compilers and linkers are able to do this kind of "code bloat reduction" on their own.
>
> Cheers!
> SG
>