basic¶

std::move¶

using a move constructor, a std::vector could just copy its internal pointer to data to the new object, leaving the moved object in an incorrect state, avoiding to copy all data.

local and global static variables¶

• The name of the local is only accessible within the function, and has no linkage
• Local is initialized the first time execution reaches the definition, not necessarily during the program's initialisation phases

Const member functions¶

A "const function", denoted with the keyword const after a function declaration, makes it a compiler error for this class function to change a member variable of the class.

A function becomes const when const keyword is used in function’s declaration. The idea of const functions is not allow them to modify the object on which they are called.

#include<iostream> 
using namespace std; 

class Test { 
    int value; 
public: 
    Test(int v = 0) {value = v;}       
    // we get compiler error if we add a line like "value = 100;" in this function
    int getValue() const {return value;}   
}; 

int main() { 
    Test t(20); 
    cout << t.getValue(); 
    return 0; 
} 

mutable keyword¶

The mutable keyword is a way to pierce the const veil you drape over your objects. If you have a const reference or pointer to an object, you cannot modify that object in any way except when and how it is marked mutable.

With your const reference or pointer you are constrained to: only read access for any visible data members permission to call only methods that are marked as const. The mutable exception makes it so you can now write or set data members that are marked mutable. That's the only externally visible difference.

Internally those const methods that are visible to you can also write to data members that are marked mutable. Essentially the const veil is pierced comprehensively. It is completely up to the API designer to ensure that mutable doesn't destroy the const concept and is only used in useful special cases. The mutable keyword helps because it clearly marks data members that are subject to these special cases.

In practice you can use const obsessively throughout your codebase (you essentially want to "infect" your codebase with the const "disease"). In this world pointers and references are const with very few exceptions, yielding code that is easier to reason about and understand. For a interesting digression look up "referential transparency".

Without the mutable keyword you will eventually be forced to use const_cast to handle the various useful special cases it allows (caching, ref counting, debug data, etc.). Unfortunately const_cast is significantly more destructive than mutable because it forces the API client to destroy the const protection of the objects (s)he is using. Additionally it causes widespread const destruction: const_casting a const pointer or reference allows unfettered write and method calling access to visible members. In contrast mutable requires the API designer to exercise fine grained control over the const exceptions, and usually these exceptions are hidden in const methods operating on private data.

size_t¶

size_t operation can be dangerous

unsigned int vs int comparison forces conversion to unsigned

size_t i = 2;
size_t j = 4;
auto k = i - j; //a large positive value