I found in a C++ book the following:
Although we will not be doing it in this book, you can overload a
function name (or operator) so that it behaves differently when used
as an l-value and when it is used as an r-value. (Recall that an
l-value means it can be used on the left-hand side of an assignment
statement.) For example, if you want a function f to behave
differently depending on whether it is used as an l-value or an
r-value, you can do so as follows:
class SomeClass {
public:
int& f(); // will be used in any l-value invocation const
const int& f( ) const; // used in any r-value invocation ...
};
I tried this and it didn't work:
class Foo {
public:
int& id(int& a);
const int& id(int& a) const;
};
int main() {
int a;
Foo f;
f.id(a) = 2;
a = f.id(a);
cout << f.id(a) << endl;
}
int& Foo :: id(int& a) {
cout << "Bar\n";
return a;
}
const int& Foo :: id(int& a) const {
cout << "No bar !\n";
return a;
}
Have I wrongly understood it ?
Either the book's example is flat-out wrong, or you copied the wrong example from the book.
class SomeClass {
public:
int& f(); // will be used in any l-value invocation const
const int& f( ) const; // used in any r-value invocation ...
};
With this code, when you call s.f() where s is an object of type SomeClass, the first version will be called when s is non-const, and the second version will be called when s is const. Value category has nothing to do with it.
Ref-qualification looks like this:
#include <iostream>
class SomeClass {
public:
int f() & { std::cout << "lvalue\n"; }
int f() && { std::cout << "rvalue\n"; }
};
int main() {
SomeClass s; s.f(); // prints "lvalue"
SomeClass{}.f(); // prints "rvalue"
}
Ofcourse the book is correct. Let me explain the workings of an example of what the author meant :
#include <iostream>
using namespace std;
class CO
{
int _m;
public:
CO(int m) : _m(m) {}
int& m() { return _m; } // used as an l-value
int const& m() const { return _m; } // used as an r-value
};
int main()
{
CO a(1);
cout << a.m() << endl;
a.m() = 2; // here used as an l-value / overload resolution selects the correct one
cout << a.m() << endl;
return 0;
}
Output is
1
2
What you misunderstood is the function signature. You see when you have an argument &arg (as in id(&arg)) you pretty much predefine the l-valuness of it, so returning it through a const or non const member function does not change a thing.
The author refers to a common writting style that allows for 'getters' and 'setters' to be declared with a signature different only in const qualifires yet compile and behave correctly.
Edit
To be more pedantic, the following phrase
Recall that an l-value means it can be used on the left-hand side of an assignment statement.
is not valid anymore. lr valuness applies to expressions, and the shortest way to explain it, is that an expression whose adress we can take, is an l-value; if it's not obtainable it's an r-value.
So the syntax to which the author refers to, enforces the member function to be used correctly (correct compilation / overload resolution) at both sides of the assignment operator. This nowdays is no longer relevant to lr valueness.
A const member function can only be called on a const object. It makes no difference what you do with the return value. In your example, f is non-const, so it always calls the non-const version of f(). Note that you can also overload on r-value references (&&) in C++11.
Related
1. In global scope, this gives error: redefinition of 'f'
#include <iostream>
using namespace std;
void f(int x) { cout << "f" << endl; }
void f(const int x) { cout << "f (const)" << endl; } // error: redefinition of 'f'
int main() { }
2. Defining two copy constructors (one with const, the other without) compiles
#include <iostream>
using namespace std;
class Foo {
public:
Foo(const Foo&) { cout << "copy (const)" << endl; }
Foo(Foo&) { cout << "copy" << endl; }
};
int main() { }
Question
Why is #1 a redefinition error but #2 is not?
For the second example, is there a use case for defining two copy constructors (one with const the other without)?
Only the top-level constness is ignored on parameters when checking if two functions are the same.
What does "top-level" constness mean? It means that something is actually const, as reported by std::is_const_v.
For example int *const is top-level const (because the pointer itself is const), and const int * is not (because the pointer itself is not const, even though it points to something that is const).
Something can be const at several levels, e.g. const int *const.
const int is also const at the top level, because there's only one "level" here.
If you have more than one star (e.g. int ***), then the type is top-level const only if const is placed after the rightmost star.
So, const int is const at the top level, meaning const int and int only differ in top-level constness.
But (similarly to const int *) const Foo& is const not at the top-level. It's a non-const reference to const Foo. (The references can never be const1, e.g. Foo &const doesn't compile.)
So the difference between Foo & and const Foo & is not on the top level, making Foo(Foo &) and Foo(const Foo &) different constructors.
1 Some argue that all references are effectively const because you can't make them point to a different object after they're created. But the language says they're not const, and std::is_const_v returns false for them.
There is a fundamental difference between the two.
One is an overload between int and const int. It's a value type. There is no semantic difference for the caller, the effect of const only affects the body of the function.
void f(int);
int a = 1;
const int b = 2;
f(a); // must copy the int value into the argument
f(b); // same thing.
The other is a const vs a mutable reference. It has a difference for the caller.
void f(int&);
void f(const int&);
int a = 1;
const int b = 2;
f(a); // could call f(int&) or f(int const&), but the mutable is a more closely match
f(b); // can only call f(int const&);
Since its passed by reference, the constness matter for the caller of the function. A function that tries to mutate a const object by reference must be invalid, and a non const object should be passed to the non const overload by default.
With only values, it don't matter at all. It is a new object. No matter the qualifier, it has no meaning for the caller, and it should therefore not care since it only affect the implementation.
You can even add const in definitions only if you want, since it declares the same function:
void f(int);
int main() {
f(1);
}
void f(const int a) {
std::cout << "hello " << a << std::endl;
}
Live example
As for your second question, I would say that since the addition of rvalue reference, there is little need for a copy constructor to take by mutable reference.
For example, std::auto_ptr used to have a constructor that took a mutable reference to transfer ownership, but it created all sorts of problems. But it has been completely replaced by std::unique_ptr, which uses rvalue reference to transfer ownership.
Rvalue reference ensure that you don't care for the integrity of the copied-from object, and that it's okay to steal off resources from it.
#1 is a redefinition error because even if you modify the local x it is passed by value so after the return call the value will stay the same.
I was a bit confused by the fact that the functions differ in presence/absence cv-qualifiers are equiavalent N4296::13.1/3.4 [over.load]:
Parameter declarations that differ only in the presence or absence of
const and/or volatile are equivalent.
Example:
#include <iostream>
void foo(int){ }
void foo(const int){ } //error: redifinition
int main(){ }
DEMO
Now, let me provide an example with member-functions.
#include <iostream>
struct A
{
A(){ }
void foo(){ std::cout << "foo()" << std::endl; }
void foo() const{ std::cout << "foo() const" << std::endl; }
};
A aa;
const A a;
int main(){ aa.foo(); a.foo(); }
DEMO
N4296::13.3.1/2 [over.match.funcs]
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
So, the member function declarations are different only in presence of the const-qualifier, but they are still overloadable. Doesn't it contradict to the quote from N4296::13.1/3.4 [over.load] I provided before?
The quoted passage (disclaimer: I haven't checked the quote or attribution, but anyway, this property of C++) is about top level const (and volatile) for a formal argument.
For example,
void foo( const int x );
is equivalent to
void foo( int x );
with respect to calling, checking its type, and so on. This is because there is no way it can matter to a caller whether a formal argument is const or not. That const-ness is only a restriction on what the function itself can do, not what callers can do.
And so for void foo( int ) you can provide an implementation with const:
void foo( const int x ) { cout << x << endl; }
It implements void foo( int ) because they're equivalent.
With a const member function you're instead saying that the referent for this is const. That's not a top level const. Adding that const is roughly equivalent to changing
void bar( int* p );
into
void bar( const int* p );
which are two different functions.
There is huge difference.Const member function means you can't modify data in that function.It includes in function signature and thats how compiler differentiates.Also accroding to C++ FAQ
The trailing const on foo() member function means that the
abstract (client-visible) state of the object isn't going to change.
This is slightly different from promising that the "raw bits" of the
object's struct aren't going to change. C++ compilers aren't allowed
to take the "bitwise" interpretation unless they can solve the
aliasing problem, which normally can't be solved (i.e., a non-const
alias could exist which could modify the state of the object).
#include <iostream>
struct A
{
A(){var=0; }
void foo(){ std::cout << "foo()" << std::endl; }
void foo() const{ std::cout << "foo() const" << std::endl;var=5; } //this will generate error
private:
int var;
};
A aa;
const A a;
int main(){ aa.foo(); a.foo(); }
we will get error: read-only variable is not assignable
see this http://coliru.stacked-crooked.com/
This question already has answers here:
Function dual to std::move?
(3 answers)
Closed 9 years ago.
std::move can be used to explicitly allow move semantics when the move wouldn't be already allowed implicitly (such as often when returning a local object from a function).
Now, I was wondering (esp. in the context of local return and implicit move there), if there is such a thing as the inverse of std::movethat will prevent moving the object (but still allow copying).
Does this even make sense?
std::move converts an lvalue into an rvalue, and it does this essentially by static_cast. The closest to what I can think of as the opposite are these two type casts:
static_cast<T &>(/*rvalue-expression*/)
static_cast<const T&>(/*rvalue-expression*/)
An example of this can be seen below:
#include <iostream>
void f(const int &)
{ std::cout << "const-lval-ref" << std::endl; }
void f(int &&)
{ std::cout << "rval-ref" << std::endl; }
int main()
{
f(static_cast<const int &>(3));
return 0;
}
Casting the prvalue 3 to const int & ensures that the lvalue-overload of f is chosen.
In most contexts, you get this rvalue-to-lvalue modification automatically, simply by assigning to a variable:
int a = 3;
When you use a after this line, it will be an lvalue. This is true even when a is declared as rvalue reference:
int &&a = 3;
Here, too, a becomes an lvalue (basically because it "has a name").
The only situation where I can imagine an explicit cast to have any relevant effect is my first example above. And there, when dealing with prvalues like 3 or temporaries returned from function calls by copy, the only legal cast is to const-reference (a non-const-reference is not allowed to bind to a prvalue).
The solution to prevent an object to be moved is to make the move constructor of the object private, this way the object can't be moved but can be copied.
Example with move:
enter code here
#include <iostream>
class A {
public:
std::string s;
A() : s("test") {}
A(const A& o) : s(o.s) { std::cout << "move failed!\n";}
A(A&& o) : s(std::move(o.s)) { std::cout << "move was succesfull!\n"; }
};
int main(int argc, const char * argv[])
{
A firsObject;
A secondObject = std::move(firsObject);
return 0;
}
Example with move disabled:
#include <iostream>
class A {
public:
std::string s;
A() : s("test") {}
A(const A& o) : s(o.s) { std::cout << "move failed!\n";}
private:
A(A&& o) : s(std::move(o.s)) { std::cout << "move was succesfull!\n"; }
};
int main(int argc, const char * argv[])
{
A firsObject;
A secondObject = std::move(firsObject);
return 0;
}
template<class T>
T& unmove(T&& t)
{
return t;
}
This will change the value category of the argument expression to an lvalue, no matter what it was originally.
void f(const int&); // copy version
void f(int&&); // move version
int main()
{
int i = ...;
f(42); // calls move version
f(move(i)); // calls move version
f(i); // calls copy version
f(unmove(42)); // calls copy version
f(unmove(move(i))); // calls copy version
f(unmove(i)); // calls copy version
}
Some background:
I came across something the other day that got me thinking about overload resolution in nested function calls. Consider the code below:
#include <iostream>
void printer(const int &a)
{
std::cout << a << "\n";
}
const int& func(const int &a)
{
std::cout << "const int& ";
return a;
}
int& func(int &a)
{
std::cout << "int& ";
return a;
}
int main()
{
int a = 42;
const int b = 21;
printer(func(a));
printer(func(b));
return 0;
}
This code prints
int& 42
const int& 21
So, obviously func(a) sees that a is a non-const int. The compiler must also see that the printer function wants a const int& argument. And there exists a func(...) that returns a const int&. I looked into the C++ standard and it says that const refs and refs are considered distinct parameter types (and that is why it picks the int& for func(a)).
To the question:
Is the compiler allowed to use the func(const int &) version instead of the func(int&) when calling func(a)?
(Perhaps there is some kind of optimization possibility if it sees that the result is passed to a function wanting a const int& parameter.)
Overload resolution does not consider the return type. That is, it will only look at the argument to the function and the different overloads, disregarding how the returned value is going to be used.
For a more explicit test, consider changing the non-const overload to:
void func( int& ) {}
which will fail to compile, even if there is a different similar overload that would allow the code to compile.
The following code
#include <vector>
#include <string>
#include <iostream>
std::string const& at(std::vector<std::string> const& n, int i)
{
return n[i];
}
std::vector<std::string> mkvec()
{
std::vector<std::string> n;
n.push_back("kagami");
n.push_back("misao");
return n;
}
int main()
{
std::string const& s = at(mkvec(), 0);
std::cout << s << std::endl; // D'oh!
return 0;
}
may lead to crash because the original vector is already destructed there. In C++ 2011 (c++0x) after rvalue-reference is introduced in, a deleted function declaration can be used to completely forbid calls to at if the vector argument is an rvalue
std::string const& at(std::vector<std::string>&&, int) = delete;
That looks good, but the following code still cause crash
int main()
{
std::string const& s = mkvec()[0];
std::cout << s << std::endl; // D'oh!
return 0;
}
because calls to member function operator [] (size_type) const of an rvalue object is still allowed. Is there any way can I forbid this kind of calls?
FIX:
The examples above is not what I did in real projects. I just wonder if C++ 2011 support any member function qualifying like
class A {
void func() rvalue; // Then a call on an rvalue object goes to this overload
void func() const;
};
FIX:
It's great, but I think C++ standard goes too far at this feature. Anyway, I have following code compiled on clang++ 2.9
#include <cstdio>
struct A {
A() {}
void func() &
{
puts("a");
}
void func() &&
{
puts("b");
}
void func() const &
{
puts("c");
}
};
int main()
{
A().func();
A a;
a.func();
A const b;
b.func();
return 0;
}
Thanks a lot!
No, and you shouldn't. How am I to do std::cout << at(mkvec(), 0) << std::endl;, a perfectly reasonable thing, if you've banned me from using at() on temporaries?
Storing references to temporaries is just a problem C++ programmers have to deal with, unfortunately.
To answer your new question, yes, you can do this:
class A {
void func() &; // lvalues go to this one
void func() &&; // rvalues go to this one
};
A a;
a.func(); // first overload
A().func(); // second overload
Just an idea:
To disable copying constructor on the vector somehow.
vector ( const vector<T,Allocator>& x );
Implicit copying of arrays is not that good thing anyway. (wondering why STL authors decided to define such ctor at all)
It will fix problems like you've mentioned and as a bonus will force you to use more effective version of your function:
void mkvec(std::vector<std::string>& n)
{
n.push_back("kagami");
n.push_back("misao");
}