The simplest way to understand const member functions and mutable keywords

Struct SomeType
{
Int m_a;
Void SomeMethod () const
{
M_a = 0;
}
};
The above code will not actually be compiled. Let's take a look at "SomeMethod" in another way.

Void SomeMethod () const

{

This-> m_a = 0;

}

 

Here, "this" is the implicit this pointer parameter of the member function. Although this parameter is not included in the function parameter list (so it is called implicit ), however, this parameter actually exists, and the parameter type is SomeType * const for non-const member functions. For const member functions, its type is const SomeType * const, that is, a const is added (I think the this pointer is an implicit parameter, so there is no place to put the const, so I have to put it at the end of the member function ). This explains why the above Code cannot be compiled. It also shows that the member function accesses its members through this implicit this pointer, which is the implicit this pointer, during Code definition, you can still skip writing. Of course, during compilation, the compiler automatically adds this.

 

There is still a very awkward problem: in the first version definition of SomeMethod, the const member function is defined, but in the second version, due to the upgrade, we need to change the value of a member variable. Obviously, we need to remove the const after the SomeMethod member function to compile the variable. However, this will cause another problem, if SomeMethod exists as a shared code library, we have reason to ensure the compatibility of SomeMethod versions so that the first version of the Library can be fully guaranteed, when upgrading to the second version of the database, you can compile the code successfully without changing the call code. To solve this problem, C ++ introduces the mutable keyword, which defines m_a as "mutable int m_a. This keyword will block the special optimization of const in the compilation process, not only solve this compilation problem, but also ensure the logic correctness during the runtime.

 

At this time, we may propose a "practical" approach, that is, to avoid defining the const member function. Isn't all the problems solved? (the const definition specification of function parameters, I will discuss it in the future )? In fact, const has the following obvious advantages:

 

1. const ensures that the method does not change its members from the language level, helps the method users understand its meaning and make correct calls, and also helps the method designers not violate its implementation intent, at the compilation level, try to prevent writing wrong implementation code.

2. const can expand the scope of use of this method, const SomeType c; c. someMethod (); if it is not a const member function, the Code cannot be compiled. That is to say, the call of this method will be limited by what it should have been.

3. From the execution level other than semantics, the const variable will participate in compilation optimization to a certain extent, thus improving the running efficiency, that is, the existence of the const object is necessary.