Good morning everyone,
I am studying the constant methods in C++, but I have an example which I expose below
be the class Person
class Persona
{
public:
//....
string& nombre();
const string& nombre() const;
private:
string nombre_;
};
And the definition of these public functions :
inline string& Persona::nombre() { return nombre_; }
inline const string& Persona::nombre() const {return nombre_; }
And the main program :
int main()
{
Persona p1;
p1.nombre() = "ProgrammerJR"
const Persona p2 = p1;
}
My doubts are the following:
1) We have a non-constant object (p1) and another that is p2. So I guess the example would show that when the function is overloaded, an object would call its non-const function and the constant object by overloading calls the const functions. Would that be okay?
2) In the definition of functions that I expose, it is divided into the const version for the const object and the other is for the non-const object. So in the const method definition:
inline const string& Persona::nombre() const {return nombre_; }
In the const after inline, let's say I return a data that is from a constant object, but then in the class shouldn't I have a data name_ that is a constant? Namely:
class Persona
{
//...
private:
const string nombre_;
};
Thank you all.
Your intuition is correct, but why trust your intuition when you can check it?
You can see the code working in Wandbox 三へ( へ՞ਊ ՞)へ ハッハッ.
No. The keyword
const
is a qualifier; that is, it qualifies an object. An object qualified as a constant is so in its entirety, both the object and its sub-objects.This qualification extends down (if the top object is constant, all sub-objects will be constant) but not up (if a sub-object is constant, it will not make the top object constant).
The qualification can put but cannot remove 1 , imagine:
Knowing this we can verify that what was said about sub-objects is true:
You can also see it in Wandbox 三へ( へ՞ਊ ՞)へ ハッハッ.
Other things to keep in mind .Don't return non-constant references to internal data of your objects, that breaks the encapsulation principle .
1 Unless a type conversion is used that removes the qualification, which is generally not advisable.
Right, that's the idea: it
p1
calls normal versions , andp2
(if you were to call some method, which you don't call any) it would call versionsconst
.No. _ The only way you would call that function would be on a constant object ... in which all member-variables would already be constants .
When you do
const int x
, you are saying, of course, that this object IS constant. Well, if you apply it to classesis the same: you're saying
a
IS constant... which is exactly the same as if you doThat is: applied to a class instance,
const
automagically converts all member-variables toconst
. Which is more versatile than doing it ourselves in the class definition (and we would have to make 2 different classes, one normal and oneconst
).Think of
const
it as the compiler placing the object in read-only memory; if you can't write, it doesn't matter what member-variable you intend to change: you won't be able to do it in any. In practice, it is as if you useconst
all of them.Sentences like this:
const Persona p2 = p1;
are not recommended. The statement forces p2's copy constructor to be executed, which is undefined so it will use the default copy constructor which like all "default" is unsafe and out of the programmer's control. The less is insecure. To initialize objects, the correct thing to do is to use the explicit constructor. For simple objects like these, what you do may work, but with somewhat more complex objects it won't.Also, if we declare a constant object, the compiler has to make sure that its attributes will not change during the lifetime of the object. A const object can only call const methods, and it is up to the compiler and linker to make sure that the method does not change attributes.
Greetings.