D
dervih
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?
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?