How to write a constant function reference - c++

At the moment I have a class defined similar to this:
class dummy{
public:
dummy(void(&func)(int))
: member{func}{}
void(&member)(int);
};
but I want to have member defined as a const function reference. I'm not sure exactly how to write this or if it is even possible.
P.S. PLEASE don't recommend me std::function I'm not oblivious to it's existence and have no objection to it, I just want to know whether something like this is doable.

The syntax:
Syntactically, you can achieve this through a type alias (or typedef):
using function_t = void(int); // or typedef void (function_t)(int);
class dummy {
public:
const function_t& member;
dummy(const function_t& func)
: member{func}{}
};
The semantics:
However, the "correct syntax" doesn't buy you anything: dummy is the same as
class dummy {
public:
function_t& member;
dummy(function_t& func)
: member{func}{}
};
(which, in turn is the same as the OP's definition) because the const qualifiers are ignored as per C++11 8.3.5/6:
The effect of a cv-qualifier-seq in a function declarator is not the same as adding cv-qualification on top of the function type. In the latter case, the cv-qualifiers are ignored. [ Note: a function type that has a cv-qualifier-seq is not a cv-qualified type; there are no cv-qualified function types. —end note ]
What about rvalues?
As far as I undestand (from a comment to user657267's answer) the motivation for taking the argument as reference to const was to enable passing rvalues (temporaries):
void f(int) { }
function_t make_function() { return f; }
dummy d1(f);
dummy d2(make_function());
However, this doesn't compile, not because of dummy, but because make_function returns a function which is forbiden by C++11 8.3.5/8
If the type of a parameter includes a type of the form “pointer to array of unknown bound of T” or “reference to array of unknown bound of T,” the program is ill-formed.99 Functions shall not have a return type of type array or function, although they may have a return type of type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays of pointers to functions.
A natural "solution" would be returning a reference:
function& make_function() { return f; }
or
function&& make_function() { return f; }
In both cases, the type of the expression make_function() is an lvalue (which defies the purpose of dummy using reference to const to enable passing rvalues) as per C++11 5.2.2/10
A function call is an lvalue if the result type is an lvalue reference type or an rvalue reference to function type, an xvalue if the result type is an rvalue reference to object type, and a prvalue otherwise.
Actually, value category is not an issue here. With any legal declaration of make_function and any definition of dummy seem above the declarations of d1 and d2 work fine.
Nevertheless, the mentioned comment to user657267's answer talks about passing a lambda but a reference to function cannot bind to lambda expression because it has a different type:
dummy d3([](int){}); // Error!
The suggested solution
Instead of references use pointers:
using function_t = void(int); // or typedef void (function_t)(int);
class dummy {
public:
function_t* member;
dummy(function_t* func)
: member{func}{}
};
void f(int) { }
function_t& make_function() { return f; }
dummy d1(f); // OK
dummy d2(make_function()); // OK
dummy d3([](int){}); // OK
Final remarks:
Again, declaring const function_t* member and dummy(const function_t* func) doesn't buy you anything because, as per references, the const qualifiers are ignored.
The initialization of d1 and d2 work because functions are implicitly converted to pointer to functions (see C++ 4.3/1).
If a function argument is of function type, the compiler changes its type to a pointer to function. Hence, dummy's constructor can be declared as dummy(function_t func);.
The initialization of d3 works because captureless lambdas are implicitly converted to pointer to functions. It wouldn't work for lambdas with captures.

Related

An issue about the member function qualified by volatile qualifier

#include <iostream>
struct A{
A() = default;
A(volatile const A&){}
void show()const volatile {
}
};
int main(){
volatile A a;
//A b = std::move(a); // ill-formed
std::move(a).show(); //OK
}
Consider the example, the results of the example are out of my understanding about some relevant rules.
For A b = std::move(a);, it's ill-formed, because it violates the following rule, that is:
dcl.init.ref#5.2
Otherwise, if the reference is an lvalue reference to a type that is not const-qualified or is volatile-qualified, the program is ill-formed.
That means, a lvalue reference to const volatile-qualified T cannot bind to any rvalue even though they're reference-compatible. A b = std::move(a); obviously violates this rule, hence it's ill-formed.
However I don't know why compile std::move(a).show();without reporting wrong. According to this rule:
For non-static member functions, the type of the implicit object parameter is
“lvalue reference to cv X” for functions declared without a ref-qualifier or with the & ref-qualifier
The type of the implicit object parameter of member function show will be volatile const A& . In general, it definitely violates [dcl.init.ref#5.2]. If change the definition of member function show to:
void show() volatile const& {
}
std::move(a).show(); will be ill-formed. So must be some magic in the following rule that make std::move(a).show(); be compiled before changing show. The rule is:
over.match.funcs#general-5
For non-static member functions declared without a ref-qualifier, an additional rule applies:
even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.
Honestly, I really don't know what does the wording "in all other respects" mean? And what does the "the type of the implicit object parameter" refer to? Does the "type" refer to volatile const A& or the referenced type volatile const A? The wording is very vague. Anyhow, lvalue reference to const volatile T cannot bind to any rvalue of type T. So, how to interpret that?
As a contrast:
#include <iostream>
struct B{
void show(){}
};
int main(){
volatile B b;
std::move(b).show(); //ill-formed
}
the type of the implicit object parameter of show would be B&, According to [over.match.funcs#general-5], even though ignore const-qualifier, it's still ill-formed due to it discards the volatile-qualifier. From this example, it implies that, For this sentence "in all other respects the argument can be converted to the type of the implicit object parameter", where the type should refer to reference type rather than the type the reference refers to. If the magic is this, it's still not sufficient to make std::move(a).show(); to be well-formed.
So, how to interpret these issues? I don't know how to use [over.match.funcs#general-5] to interpret these two examples.
struct A {
A() = default;
A(volatile const A &) {}
void show() const volatile {}
};
int main() {
volatile A a;
std::move(a).show(); // OK
}
The implied object parameter for the member function show() is, as per [over.match.funcs]/4, const volatile A&, such that for the purpose of overload resolution, we may, as per [over.match.funcs]/5, consider the data member function as
void show(const volatile A&);
Now, with this in mind, let's first simplify the example, with the purpose of:
Comparing why an rvalue reference of A seemingly may bind to an implied object parameter or type const volatile A& but not to say a function parameter of the same type when the parameter is for a regular free function.
Thus, consider the following simplified example:
#include <memory>
struct A {
void show() const volatile {}
};
void g(const volatile A &) { }
int main() {
volatile A a;
g(std::move(a)); // (i) Error.
std::move(a).show(); // (ii) OK.
}
The error message at (i), in GCC (10.1.0) is:
error: cannot bind non-const lvalue reference of type const volatile A& to an rvalue of type std::remove_reference<volatile A&>::type
{aka volatile A}
which is expected (as you have noted yourself) as per [dcl.init.ref]/5.2, which disallows rvalues to bind, in initialization, to volatile references, even if they are const-qualified.
Then why is (ii) accepted? Or, conversely, why does the restriction of [dcl.init.ref]/5.2 apparently not apply for the similar case of the implicit object parameter of a member function?
The answer lies in
[over.match.funcs
]/5.1, which contains an exception for member functions declared without a ref-qualifier:
[over.match.funcs
]/5 [...] For non-static member functions declared without a ref-qualifier, an additional rule applies:
/5.1 even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.
[over.match.funcs ]/5.1 removes the prohibation of [dcl.init.ref]/5 regarding rvalues (rvalue binding), and the remaining criteria is applied to whether argument (rvalue ignored; volatile A) can be ("in all other respects") converted to the implicit object parameter (const volatile A&). As the implicit object parameter, as shown above, in this case is always an lvalue reference, "in all other respects" here essentially means that the implicit object parameter is reference-compatible (as per [dcl.init.ref]/4) with the (rvalue ignored) argument type.
// [over.match.funcs ]/5.1 special case: rvalue prohibition waived
volatile A a; // argument: a
const volatile A& aref = a; // ok, reference-compatible
// ^^^^^^^^^^^^^^^^^ implicit object parameter
Arguably [over.match.funcs]/5.1 could be clearer on that it applies both for the case where non-const qualification (usually) prohibits from-rvalue binding, and that volatile-cv-qualification (usually) prohibits from-rvalue binding.
We may finally query the compiler(s) whether this is actually the particular rule which it uses to allow (ii), by explicitly adding the &-ref-qualifier, a change that as per [over.match.funcs]/4.1 will have no effect on the type of the implicit object parameter:
#include <memory>
struct A {
void show() const volatile & {}
};
void g(const volatile A &) { }
int main() {
volatile A a;
g(std::move(a)); // (i) Error.
std::move(a).show(); // (ii') Error.
}
As expected, if we add a &-qualifier to the show() overload, (ii) likewise fails as (i) did, albeit with another error message (GCC):
error: passing std::remove_reference<volatile A&>::type {aka volatile A} as this argument discards qualifiers
For this error, Clang (10.0.0) arguably has a more on-spot error message:
error: this argument to member function show is an rvalue, but function has non-const lvalue ref-qualifier

What are the difference between these functions [duplicate]

Came across a proposal called "rvalue reference for *this" in clang's C++11 status page.
I've read quite a bit about rvalue references and understood them, but I don't think I know about this. I also couldn't find much resources on the web using the terms.
There's a link to the proposal paper on the page: N2439 (Extending move semantics to *this), but I'm also not getting much examples from there.
What is this feature about?
First, "ref-qualifiers for *this" is a just a "marketing statement". The type of *this never changes, see the bottom of this post. It's way easier to understand it with this wording though.
Next, the following code chooses the function to be called based on the ref-qualifier of the "implicit object parameter" of the function†:
// t.cpp
#include <iostream>
struct test{
void f() &{ std::cout << "lvalue object\n"; }
void f() &&{ std::cout << "rvalue object\n"; }
};
int main(){
test t;
t.f(); // lvalue
test().f(); // rvalue
}
Output:
$ clang++ -std=c++0x -stdlib=libc++ -Wall -pedantic t.cpp
$ ./a.out
lvalue object
rvalue object
The whole thing is done to allow you to take advantage of the fact when the object the function is called on is an rvalue (unnamed temporary, for example). Take the following code as a further example:
struct test2{
std::unique_ptr<int[]> heavy_resource;
test2()
: heavy_resource(new int[500]) {}
operator std::unique_ptr<int[]>() const&{
// lvalue object, deep copy
std::unique_ptr<int[]> p(new int[500]);
for(int i=0; i < 500; ++i)
p[i] = heavy_resource[i];
return p;
}
operator std::unique_ptr<int[]>() &&{
// rvalue object
// we are garbage anyways, just move resource
return std::move(heavy_resource);
}
};
This may be a bit contrived, but you should get the idea.
Note that you can combine the cv-qualifiers (const and volatile) and ref-qualifiers (& and &&).
Note: Many standard quotes and overload resolution explanation after here!
† To understand how this works, and why #Nicol Bolas' answer is at least partly wrong, we have to dig in the C++ standard for a bit (the part explaining why #Nicol's answer is wrong is at the bottom, if you're only interested in that).
Which function is going to be called is determined by a process called overload resolution. This process is fairly complicated, so we'll only touch the bit that is important to us.
First, it's important to see how overload resolution for member functions works:
§13.3.1 [over.match.funcs]
p2 The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. [...]
p3 Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on.
Why do we even need to compare member and non-member functions? Operator overloading, that's why. Consider this:
struct foo{
foo& operator<<(void*); // implementation unimportant
};
foo& operator<<(foo&, char const*); // implementation unimportant
You'd certainly want the following to call the free function, don't you?
char const* s = "free foo!\n";
foo f;
f << s;
That's why member and non-member functions are included in the so-called overload-set. To make the resolution less complicated, the bold part of the standard quote exists. Additionally, this is the important bit for us (same clause):
p4 For non-static member functions, the type of the implicit object parameter is
“lvalue reference to cv X” for functions declared without a ref-qualifier or with the & ref-qualifier
“rvalue reference to cv X” for functions declared with the && ref-qualifier
where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [...]
p5 During overload resolution [...] [t]he implicit object parameter [...] retains its identity since conversions on the corresponding argument shall obey these additional rules:
no temporary object can be introduced to hold the argument for the implicit object parameter; and
no user-defined conversions can be applied to achieve a type match with it
[...]
(The last bit just means that you can't cheat overload resolution based on implicit conversions of the object a member function (or operator) is called on.)
Let's take the first example at the top of this post. After the aforementioned transformation, the overload-set looks something like this:
void f1(test&); // will only match lvalues, linked to 'void test::f() &'
void f2(test&&); // will only match rvalues, linked to 'void test::f() &&'
Then the argument list, containing an implied object argument, is matched against the parameter-list of every function contained in the overload-set. In our case, the argument list will only contain that object argument. Let's see how that looks like:
// first call to 'f' in 'main'
test t;
f1(t); // 't' (lvalue) can match 'test&' (lvalue reference)
// kept in overload-set
f2(t); // 't' not an rvalue, can't match 'test&&' (rvalue reference)
// taken out of overload-set
If, after all overloads in the set are tested, only one remains, the overload resolution succeeded and the function linked to that transformed overload is called. The same goes for the second call to 'f':
// second call to 'f' in 'main'
f1(test()); // 'test()' not an lvalue, can't match 'test&' (lvalue reference)
// taken out of overload-set
f2(test()); // 'test()' (rvalue) can match 'test&&' (rvalue reference)
// kept in overload-set
Note however that, had we not provided any ref-qualifier (and as such not overloaded the function), that f1 would match an rvalue (still §13.3.1):
p5 [...] For non-static member functions declared without a ref-qualifier, an additional rule applies:
even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.
struct test{
void f() { std::cout << "lvalue or rvalue object\n"; }
};
int main(){
test t;
t.f(); // OK
test().f(); // OK too
}
Now, onto why #Nicol's answer is atleast partly wrong. He says:
Note that this declaration changes the type of *this.
That is wrong, *this is always an lvalue:
§5.3.1 [expr.unary.op] p1
The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points.
§9.3.2 [class.this] p1
In the body of a non-static (9.3) member function, the keyword this is a prvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. [...]
There is an additional use case for the lvalue ref-qualifier form. C++98 has language that allows non-const member functions to be called for class instances that are rvalues. This leads to all kinds of weirdness that is against the very concept of rvalueness and deviates from how built-in types work:
struct S {
 S& operator ++();
S* operator &();
};
S() = S(); // rvalue as a left-hand-side of assignment!
S& foo = ++S(); // oops, dangling reference
&S(); // taking address of rvalue...
Lvalue ref-qualifiers solve these problems:
struct S {
S& operator ++() &;
S* operator &() &;
const S& operator =(const S&) &;
};
Now the operators work like those of the builtin types, accepting only lvalues.
Let's say you have two functions on a class, both with the same name and signature. But one of them is declared const:
void SomeFunc() const;
void SomeFunc();
If a class instance is not const, overload resolution will preferentially select the non-const version. If the instance is const, the user can only call the const version. And the this pointer is a const pointer, so the instance cannot be changed.
What "r-value reference for this` does is allow you to add another alternative:
void RValueFunc() &&;
This allows you to have a function that can only be called if the user calls it through a proper r-value. So if this is in the type Object:
Object foo;
foo.RValueFunc(); //error: no `RValueFunc` version exists that takes `this` as l-value.
Object().RValueFunc(); //calls the non-const, && version.
This way, you can specialize behavior based on whether the object is being accessed via an r-value or not.
Note that you are not allowed to overload between the r-value reference versions and the non-reference versions. That is, if you have a member function name, all of its versions either use the l/r-value qualifiers on this, or none of them do. You can't do this:
void SomeFunc();
void SomeFunc() &&;
You must do this:
void SomeFunc() &;
void SomeFunc() &&;
Note that this declaration changes the type of *this. This means that the && versions all access members as r-value references. So it becomes possible to easily move from within the object. The example given in the first version of the proposal is (note: the following may not be correct with the final version of C++11; it's straight from the initial "r-value from this" proposal):
class X {
std::vector<char> data_;
public:
// ...
std::vector<char> const & data() const & { return data_; }
std::vector<char> && data() && { return data_; }
};
X f();
// ...
X x;
std::vector<char> a = x.data(); // copy
std::vector<char> b = f().data(); // move

C++ ampersand '&' at the end of member function declaration [duplicate]

Came across a proposal called "rvalue reference for *this" in clang's C++11 status page.
I've read quite a bit about rvalue references and understood them, but I don't think I know about this. I also couldn't find much resources on the web using the terms.
There's a link to the proposal paper on the page: N2439 (Extending move semantics to *this), but I'm also not getting much examples from there.
What is this feature about?
First, "ref-qualifiers for *this" is a just a "marketing statement". The type of *this never changes, see the bottom of this post. It's way easier to understand it with this wording though.
Next, the following code chooses the function to be called based on the ref-qualifier of the "implicit object parameter" of the function†:
// t.cpp
#include <iostream>
struct test{
void f() &{ std::cout << "lvalue object\n"; }
void f() &&{ std::cout << "rvalue object\n"; }
};
int main(){
test t;
t.f(); // lvalue
test().f(); // rvalue
}
Output:
$ clang++ -std=c++0x -stdlib=libc++ -Wall -pedantic t.cpp
$ ./a.out
lvalue object
rvalue object
The whole thing is done to allow you to take advantage of the fact when the object the function is called on is an rvalue (unnamed temporary, for example). Take the following code as a further example:
struct test2{
std::unique_ptr<int[]> heavy_resource;
test2()
: heavy_resource(new int[500]) {}
operator std::unique_ptr<int[]>() const&{
// lvalue object, deep copy
std::unique_ptr<int[]> p(new int[500]);
for(int i=0; i < 500; ++i)
p[i] = heavy_resource[i];
return p;
}
operator std::unique_ptr<int[]>() &&{
// rvalue object
// we are garbage anyways, just move resource
return std::move(heavy_resource);
}
};
This may be a bit contrived, but you should get the idea.
Note that you can combine the cv-qualifiers (const and volatile) and ref-qualifiers (& and &&).
Note: Many standard quotes and overload resolution explanation after here!
† To understand how this works, and why #Nicol Bolas' answer is at least partly wrong, we have to dig in the C++ standard for a bit (the part explaining why #Nicol's answer is wrong is at the bottom, if you're only interested in that).
Which function is going to be called is determined by a process called overload resolution. This process is fairly complicated, so we'll only touch the bit that is important to us.
First, it's important to see how overload resolution for member functions works:
§13.3.1 [over.match.funcs]
p2 The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. [...]
p3 Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on.
Why do we even need to compare member and non-member functions? Operator overloading, that's why. Consider this:
struct foo{
foo& operator<<(void*); // implementation unimportant
};
foo& operator<<(foo&, char const*); // implementation unimportant
You'd certainly want the following to call the free function, don't you?
char const* s = "free foo!\n";
foo f;
f << s;
That's why member and non-member functions are included in the so-called overload-set. To make the resolution less complicated, the bold part of the standard quote exists. Additionally, this is the important bit for us (same clause):
p4 For non-static member functions, the type of the implicit object parameter is
“lvalue reference to cv X” for functions declared without a ref-qualifier or with the & ref-qualifier
“rvalue reference to cv X” for functions declared with the && ref-qualifier
where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [...]
p5 During overload resolution [...] [t]he implicit object parameter [...] retains its identity since conversions on the corresponding argument shall obey these additional rules:
no temporary object can be introduced to hold the argument for the implicit object parameter; and
no user-defined conversions can be applied to achieve a type match with it
[...]
(The last bit just means that you can't cheat overload resolution based on implicit conversions of the object a member function (or operator) is called on.)
Let's take the first example at the top of this post. After the aforementioned transformation, the overload-set looks something like this:
void f1(test&); // will only match lvalues, linked to 'void test::f() &'
void f2(test&&); // will only match rvalues, linked to 'void test::f() &&'
Then the argument list, containing an implied object argument, is matched against the parameter-list of every function contained in the overload-set. In our case, the argument list will only contain that object argument. Let's see how that looks like:
// first call to 'f' in 'main'
test t;
f1(t); // 't' (lvalue) can match 'test&' (lvalue reference)
// kept in overload-set
f2(t); // 't' not an rvalue, can't match 'test&&' (rvalue reference)
// taken out of overload-set
If, after all overloads in the set are tested, only one remains, the overload resolution succeeded and the function linked to that transformed overload is called. The same goes for the second call to 'f':
// second call to 'f' in 'main'
f1(test()); // 'test()' not an lvalue, can't match 'test&' (lvalue reference)
// taken out of overload-set
f2(test()); // 'test()' (rvalue) can match 'test&&' (rvalue reference)
// kept in overload-set
Note however that, had we not provided any ref-qualifier (and as such not overloaded the function), that f1 would match an rvalue (still §13.3.1):
p5 [...] For non-static member functions declared without a ref-qualifier, an additional rule applies:
even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.
struct test{
void f() { std::cout << "lvalue or rvalue object\n"; }
};
int main(){
test t;
t.f(); // OK
test().f(); // OK too
}
Now, onto why #Nicol's answer is atleast partly wrong. He says:
Note that this declaration changes the type of *this.
That is wrong, *this is always an lvalue:
§5.3.1 [expr.unary.op] p1
The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points.
§9.3.2 [class.this] p1
In the body of a non-static (9.3) member function, the keyword this is a prvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. [...]
There is an additional use case for the lvalue ref-qualifier form. C++98 has language that allows non-const member functions to be called for class instances that are rvalues. This leads to all kinds of weirdness that is against the very concept of rvalueness and deviates from how built-in types work:
struct S {
 S& operator ++();
S* operator &();
};
S() = S(); // rvalue as a left-hand-side of assignment!
S& foo = ++S(); // oops, dangling reference
&S(); // taking address of rvalue...
Lvalue ref-qualifiers solve these problems:
struct S {
S& operator ++() &;
S* operator &() &;
const S& operator =(const S&) &;
};
Now the operators work like those of the builtin types, accepting only lvalues.
Let's say you have two functions on a class, both with the same name and signature. But one of them is declared const:
void SomeFunc() const;
void SomeFunc();
If a class instance is not const, overload resolution will preferentially select the non-const version. If the instance is const, the user can only call the const version. And the this pointer is a const pointer, so the instance cannot be changed.
What "r-value reference for this` does is allow you to add another alternative:
void RValueFunc() &&;
This allows you to have a function that can only be called if the user calls it through a proper r-value. So if this is in the type Object:
Object foo;
foo.RValueFunc(); //error: no `RValueFunc` version exists that takes `this` as l-value.
Object().RValueFunc(); //calls the non-const, && version.
This way, you can specialize behavior based on whether the object is being accessed via an r-value or not.
Note that you are not allowed to overload between the r-value reference versions and the non-reference versions. That is, if you have a member function name, all of its versions either use the l/r-value qualifiers on this, or none of them do. You can't do this:
void SomeFunc();
void SomeFunc() &&;
You must do this:
void SomeFunc() &;
void SomeFunc() &&;
Note that this declaration changes the type of *this. This means that the && versions all access members as r-value references. So it becomes possible to easily move from within the object. The example given in the first version of the proposal is (note: the following may not be correct with the final version of C++11; it's straight from the initial "r-value from this" proposal):
class X {
std::vector<char> data_;
public:
// ...
std::vector<char> const & data() const & { return data_; }
std::vector<char> && data() && { return data_; }
};
X f();
// ...
X x;
std::vector<char> a = x.data(); // copy
std::vector<char> b = f().data(); // move

How can const make a function overloads?

I wrote this code in C++:
class Foo
{
public:
int& fun(){return var;} // 1st fun
int fun() const {return var;} // 2rd fun
private:
int var;
};
int main()
{
Foo foo;
int i = foo.fun();
return 0;
}
I know that C++ cannot discriminate overloading function by return value,but why when I added a const to 2rd function ,overloading can work ?
What the 'const' have done ?
Compiler cannot discriminate by return type because return values can undergo conversion before the assignment is performed. The object on which the function is invoked, on the other hand, is a parameter (albeit an implicit one) to the function, so the compiler can discriminate on it.
Const is used in the following way:
Foo inst1;
const Foo inst2;
inst1.fun(); // 1st fun
inst2.fun(); // 2nd fun
Const after the name of the function refers to the implicit this parameter. So, for inst1 it will Foo* and for inst2 const Foo*. This will guide the overload.
The return value is not used for selecting the overload. Methods/functions with the same set of params and different types of return value are not allowed on the same layer.
For what it's worth, the language from the standard (§13.3.1/3,4):
Similarly, when appropriate, the context can construct an argument list that contains an implied object
argument to denote the object to be operated on. Since arguments and parameters are associated by position within their respective lists, the convention is that the implicit object parameter, if present, is
always the first parameter and the implied object argument, if present, is always the first argument.
For non-static member functions, the type of the implicit object parameter is
— “lvalue reference to cv X” for functions declared without a ref-qualifier or with the & ref-qualifier
— “rvalue reference to cv X” for functions declared with the && ref-qualifier
where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [ Example: for a const member function of class X, the extra parameter is assumed to have type “reference to const X”. —end example ]

What is "rvalue reference for *this"?

Came across a proposal called "rvalue reference for *this" in clang's C++11 status page.
I've read quite a bit about rvalue references and understood them, but I don't think I know about this. I also couldn't find much resources on the web using the terms.
There's a link to the proposal paper on the page: N2439 (Extending move semantics to *this), but I'm also not getting much examples from there.
What is this feature about?
First, "ref-qualifiers for *this" is a just a "marketing statement". The type of *this never changes, see the bottom of this post. It's way easier to understand it with this wording though.
Next, the following code chooses the function to be called based on the ref-qualifier of the "implicit object parameter" of the function†:
// t.cpp
#include <iostream>
struct test{
void f() &{ std::cout << "lvalue object\n"; }
void f() &&{ std::cout << "rvalue object\n"; }
};
int main(){
test t;
t.f(); // lvalue
test().f(); // rvalue
}
Output:
$ clang++ -std=c++0x -stdlib=libc++ -Wall -pedantic t.cpp
$ ./a.out
lvalue object
rvalue object
The whole thing is done to allow you to take advantage of the fact when the object the function is called on is an rvalue (unnamed temporary, for example). Take the following code as a further example:
struct test2{
std::unique_ptr<int[]> heavy_resource;
test2()
: heavy_resource(new int[500]) {}
operator std::unique_ptr<int[]>() const&{
// lvalue object, deep copy
std::unique_ptr<int[]> p(new int[500]);
for(int i=0; i < 500; ++i)
p[i] = heavy_resource[i];
return p;
}
operator std::unique_ptr<int[]>() &&{
// rvalue object
// we are garbage anyways, just move resource
return std::move(heavy_resource);
}
};
This may be a bit contrived, but you should get the idea.
Note that you can combine the cv-qualifiers (const and volatile) and ref-qualifiers (& and &&).
Note: Many standard quotes and overload resolution explanation after here!
† To understand how this works, and why #Nicol Bolas' answer is at least partly wrong, we have to dig in the C++ standard for a bit (the part explaining why #Nicol's answer is wrong is at the bottom, if you're only interested in that).
Which function is going to be called is determined by a process called overload resolution. This process is fairly complicated, so we'll only touch the bit that is important to us.
First, it's important to see how overload resolution for member functions works:
§13.3.1 [over.match.funcs]
p2 The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. [...]
p3 Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on.
Why do we even need to compare member and non-member functions? Operator overloading, that's why. Consider this:
struct foo{
foo& operator<<(void*); // implementation unimportant
};
foo& operator<<(foo&, char const*); // implementation unimportant
You'd certainly want the following to call the free function, don't you?
char const* s = "free foo!\n";
foo f;
f << s;
That's why member and non-member functions are included in the so-called overload-set. To make the resolution less complicated, the bold part of the standard quote exists. Additionally, this is the important bit for us (same clause):
p4 For non-static member functions, the type of the implicit object parameter is
“lvalue reference to cv X” for functions declared without a ref-qualifier or with the & ref-qualifier
“rvalue reference to cv X” for functions declared with the && ref-qualifier
where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [...]
p5 During overload resolution [...] [t]he implicit object parameter [...] retains its identity since conversions on the corresponding argument shall obey these additional rules:
no temporary object can be introduced to hold the argument for the implicit object parameter; and
no user-defined conversions can be applied to achieve a type match with it
[...]
(The last bit just means that you can't cheat overload resolution based on implicit conversions of the object a member function (or operator) is called on.)
Let's take the first example at the top of this post. After the aforementioned transformation, the overload-set looks something like this:
void f1(test&); // will only match lvalues, linked to 'void test::f() &'
void f2(test&&); // will only match rvalues, linked to 'void test::f() &&'
Then the argument list, containing an implied object argument, is matched against the parameter-list of every function contained in the overload-set. In our case, the argument list will only contain that object argument. Let's see how that looks like:
// first call to 'f' in 'main'
test t;
f1(t); // 't' (lvalue) can match 'test&' (lvalue reference)
// kept in overload-set
f2(t); // 't' not an rvalue, can't match 'test&&' (rvalue reference)
// taken out of overload-set
If, after all overloads in the set are tested, only one remains, the overload resolution succeeded and the function linked to that transformed overload is called. The same goes for the second call to 'f':
// second call to 'f' in 'main'
f1(test()); // 'test()' not an lvalue, can't match 'test&' (lvalue reference)
// taken out of overload-set
f2(test()); // 'test()' (rvalue) can match 'test&&' (rvalue reference)
// kept in overload-set
Note however that, had we not provided any ref-qualifier (and as such not overloaded the function), that f1 would match an rvalue (still §13.3.1):
p5 [...] For non-static member functions declared without a ref-qualifier, an additional rule applies:
even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.
struct test{
void f() { std::cout << "lvalue or rvalue object\n"; }
};
int main(){
test t;
t.f(); // OK
test().f(); // OK too
}
Now, onto why #Nicol's answer is atleast partly wrong. He says:
Note that this declaration changes the type of *this.
That is wrong, *this is always an lvalue:
§5.3.1 [expr.unary.op] p1
The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points.
§9.3.2 [class.this] p1
In the body of a non-static (9.3) member function, the keyword this is a prvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. [...]
There is an additional use case for the lvalue ref-qualifier form. C++98 has language that allows non-const member functions to be called for class instances that are rvalues. This leads to all kinds of weirdness that is against the very concept of rvalueness and deviates from how built-in types work:
struct S {
 S& operator ++();
S* operator &();
};
S() = S(); // rvalue as a left-hand-side of assignment!
S& foo = ++S(); // oops, dangling reference
&S(); // taking address of rvalue...
Lvalue ref-qualifiers solve these problems:
struct S {
S& operator ++() &;
S* operator &() &;
const S& operator =(const S&) &;
};
Now the operators work like those of the builtin types, accepting only lvalues.
Let's say you have two functions on a class, both with the same name and signature. But one of them is declared const:
void SomeFunc() const;
void SomeFunc();
If a class instance is not const, overload resolution will preferentially select the non-const version. If the instance is const, the user can only call the const version. And the this pointer is a const pointer, so the instance cannot be changed.
What "r-value reference for this` does is allow you to add another alternative:
void RValueFunc() &&;
This allows you to have a function that can only be called if the user calls it through a proper r-value. So if this is in the type Object:
Object foo;
foo.RValueFunc(); //error: no `RValueFunc` version exists that takes `this` as l-value.
Object().RValueFunc(); //calls the non-const, && version.
This way, you can specialize behavior based on whether the object is being accessed via an r-value or not.
Note that you are not allowed to overload between the r-value reference versions and the non-reference versions. That is, if you have a member function name, all of its versions either use the l/r-value qualifiers on this, or none of them do. You can't do this:
void SomeFunc();
void SomeFunc() &&;
You must do this:
void SomeFunc() &;
void SomeFunc() &&;
Note that this declaration changes the type of *this. This means that the && versions all access members as r-value references. So it becomes possible to easily move from within the object. The example given in the first version of the proposal is (note: the following may not be correct with the final version of C++11; it's straight from the initial "r-value from this" proposal):
class X {
std::vector<char> data_;
public:
// ...
std::vector<char> const & data() const & { return data_; }
std::vector<char> && data() && { return data_; }
};
X f();
// ...
X x;
std::vector<char> a = x.data(); // copy
std::vector<char> b = f().data(); // move