Note that the only difference between the struct and class keywords is that by default, the member variables, member functions, and base classes of a struct are public, while in a class they are private. C++ programmers tend to call it a class if it has constructors and destructors, and the ability to enforce its own invariants; or a struct if it's just a simple collection of values, but the C++ language itself makes no distinction.

C++ is not a memory-managed language. Dynamically allocated memory (i.e. objects created with new) will be "leaked" if it is not explicitly deallocated (with delete). It is the programmer's responsibility to ensure that the dynamically allocated memory is freed before discarding the last pointer to that object.

Smart pointers can be used to automatically manage the scope of dynamically allocated memory (i.e. when the last pointer reference goes out of scope it is deleted).

Smart pointers are preferred over "raw" pointers in most cases. They make the ownership semantics of dynamically allocated memory explicit, by communicating in their names whether an object is intended to be shared or uniquely owned.

Use #include <memory> to be able to use smart pointers.

Ambiguities can occur when one type can be implicitly converted into more than one type and there is no matching function for that specific type.

For example:

void foo(double, double);
void foo(long, long);

//Call foo with 2 ints
foo(1, 2); //Function call is ambiguous - int can be converted into a double/long at the same time 

Use of an std::vector requires the inclusion of the <vector> header using #include <vector>.

Elements in a std::vector are stored contiguously on the free store. It should be noted that when vectors are nested as in std::vector<std::vector<int> >, the elements of each vector are contiguous, but each vector allocates its own underlying buffer on the free store.

C++17 (the current draft) introduces constexpr lambdas, basically lambdas that can be evaluated at compile time. A lambda is automatically constexpr if it satisfies constexpr requirements, but you can also specify it using the constexpr keyword:

//Explicitly define this lambdas as constexpr
[]() constexpr {
    //Do stuff
}

• To use any of std::map or std::multimap the header file <map> should be included.

• std::map and std::multimap both keep their elements sorted according to the ascending order of keys. In case of std::multimap, no sorting occurs for the values of the same key.

• The basic difference between std::map and std::multimap is that the std::map one does not allow duplicate values for the same key where std::multimap does.

• Maps are implemented as binary search trees. So search(), insert(), erase() takes Θ(log n) time in average. For constant time operation use std::unordered_map.

• size() and empty() functions have Θ(1) time complexity, number of nodes is cached to avoid walking through tree each time these functions are called.

Some notes:

• Two std::thread objects can never represent the same thread.
• A std::thread object can be in a state where it doesn't represent any thread (i.e. after a move, after calling join, etc.).

Preprocessor statements are executed before your source files are handed to the compiler. They are capable of very low level conditional logic. Since preprocessor constructs (e.g. object-like macros) aren't typed like normal functions (the preprocessing step happens before compilation) the compiler cannot enforce type checks, they should therefore be carefully used.

RAII stands for Resource Acquisition Is Initialization. Also occasionally referred to as SBRM (Scope-Based Resource Management) or RRID (Resource Release Is Destruction), RAII is an idiom used to tie resources to object lifetime. In C++, the destructor for an object always runs when an object goes out of scope - we can take advantage of that to tie resource cleanup into object destruction.

Any time you need to acquire some resource (e.g. a lock, a file handle, an allocated buffer) that you will eventually need to release, you should consider using an object to handle that resource management for you. Stack unwinding will happen regardless of exception or early scope exit, so the resource handler object will clean up the resource for you without you having to carefully consider all possible current and future code paths.

It's worth noting that RAII doesn't completely free the developer of thinking about the lifetime of resources. One case is, obviously, a crash or exit() call, which will prevent destructors from being called. Since the OS will clean up process-local resources like memory after a process ends, this is not a problem in most cases. However with system resources (i.e. named pipes, lock files, shared memory) you still need facilities to deal with the case where a process didn't clean up after itself, i.e. on startup test if the lock file is there, if it is, verify the process with the pid actually exists, then act accordingly.

Another situation is when a unix process calls a function from the exec-family, i.e. after a fork-exec to create a new process. Here, the child process will have a full copy of the parents memory (including the RAII objects) but once exec was called, none of the destructors will be called in that process. On the other hand, if a process is forked and neither of the processes call exec, all resources are cleaned up in both processes. This is correct only for all resources that were actually duplicated in the fork, but with system resources, both processes will only have a reference to the resource (i.e. the path to a lock file) and will both try to release it individually, potentially causing the other process to fail.

Random number generation in C++ is provided by the <random> header. This header defines random devices, pseudo-random generators and distributions.

Random devices return random numbers provided by operating system. They should either be used for initialization of pseudo-random generators or directly for cryptographic purposes.

Pseudo-random generators return integer pseudo-random numbers based on their initial seed. The pseudo-random number range typically spans all values of an unsigned type. All pseudo-random generators in the standard library will return the same numbers for the same initial seed for all platforms.

Distributions consume random numbers from pseudo-random generators or random devices and produce random numbers with necessary distribution. Distributions are not platform-independent and can produce different numbers for the same generators with the same initial seeds on different platforms.

The std::sort function family is found in the algorithm library.

Perfect forwarding requires forwarding references in order to preserve the ref-qualifiers of the arguments. Such references appear only in a deduced context. That is:

template<class T>
void f(T&& x) // x is a forwarding reference, because T is deduced from a call to f()
{
    g(std::forward<T>(x)); // g() will receive an lvalue or an rvalue, depending on x
}

The following does not involve perfect forwarding, because T is not deduced from the constructor call:

template<class T>
struct a
{
    a(T&& x); // x is a rvalue reference, not a forwarding reference
};

a example1(1);
  // same as a<int> example1(1);

int x = 1;
a example2(x);
  // same as a<int&> example2(x);

Overload resolution happens in several different situations

• Calls to named overloaded functions. The candidates are all the functions found by name lookup.
• Calls to class object. The candidates are usually all the overloaded function call operators of the class.
• Use of an operator. The candidates are the overloaded operator functions at namespace scope, the overloaded operator functions in the left class object (if any) and the built-in operators.
• Overload resolution to find the correct conversion operator function or constructor to invoke for an initialization
  • For non-list direct initialization (Class c(value)), the candidates are constructors of Class.
  • For non-list copy initialization (Class c = value) and for finding the user defined conversion function to invoke in a user defined conversion sequence. The candidates are the constructors of Class and if the source is a class object, its conversion operator functions.
  • For initialization of a non-class from a class object (Nonclass c = classObject). The candidates are the conversion operator functions of the initializer object.
  • For initializing a reference with a class object (R &r = classObject), when the class has conversion operator functions that yield values that can be bound directly to r. The candidates are such conversion operator functions.
  • For list-initialization of a non-aggregate class object (Class c{1, 2, 3}), the candidates are the initializer list constructors for a first pass through overload resolution. If this doesn't find a viable candidate, a second pass through overload resolution is done, with the constructors of Class as candidates.

The pimpl idiom (pointer to implementation, sometimes referred to as opaque pointer or cheshire cat technique), reduces the compilation times of a class by moving all its private data members into a struct defined in the .cpp file.

The class owns a pointer to the implementation. This way, it can be forward declared, so that the header file does not need to #include classes that are used in private member variables.

When using the pimpl idiom, changing a private data member does not require recompiling classes that depend on it.

A variable marked as const cannot¹ be changed. Attempting to call any non-const operations on it will result in a compiler error.

_{1: Well, it can be changed through const_cast, but you should almost never use that}

The keyword auto is a typename that represents an automatically-deduced type.

It was already a reserved keyword in C++98, inherited from C. In old versions of C++, it could be used to explicitly state that a variable has automatic storage duration:

int main()
{
  auto int i = 5; // removing auto has no effect
}

That old meaning is now removed.

Bit shift operations are not portable across all processor architectures, different processors can have different bit-widths. In other words, if you wrote

int a = ~0;
int b = a << 1;

This value would be different on a 64 bit machine vs. on a 32 bit machine, or from an x86 based processor to a PIC based processor.

Endian-ness does not need to be taken into account for the bit wise operations themselves, that is, the right shift (>>) will shift the bits towards the least significant bit and an XOR will perform an exclusive or on the bits. Endian-ness only needs to be taken into account with the data itself, that is, if endian-ness is a concern for your application, it's a concern regardless of bit wise operations.

Fold Expressions are supported for the following operators

When folding over an empty sequence, a fold expression is ill-formed, except for the following three operators:

How expensive are the bitwise operations? Suppose a simple non-bit field structure:

struct foo {
    unsigned x;
    unsigned y;
}
static struct foo my_var;

In some later code:

my_var.y = 5;

If sizeof (unsigned) == 4, then x is stored at the start of the structure, and y is stored 4 bytes in. Assembly code generated may resemble:

loada register1,#myvar     ; get the address of the structure
storei register1[4],#0x05  ; put the value '5' at offset 4, e.g., set y=5

This is straightforward because x is not co-mingled with y. But imagine redefining the structure with bit fields:

struct foo {
    unsigned x : 4; /* Range 0-0x0f, or 0 through 15 */
    unsigned y : 4;
}

Both x and y will be allocated 4 bits, sharing a single byte. The structure thus takes up 1 byte, instead of 8. Consider the assembly to set y now, assuming it ends up in the upper nibble:

loada  register1,#myvar        ; get the address of the structure
loadb  register2,register1[0]  ; get the byte from memory
andb   register2,#0x0f         ; zero out y in the byte, leaving x alone
orb    register2,#0x50         ; put the 5 into the 'y' portion of the byte
stb    register1[0],register2  ; put the modified byte back into memory

This may be a good trade-off if we have thousands or millions of these structures, and it helps keeps memory in cache or prevents swapping—or could bloat the executable to worsen these problems and slow processing. As with all things, use good judgement.

Device driver use: Avoid bit fields as a clever implementation strategy for device drivers. Bit field storage layouts are not necessarily consistent between compilers, making such implementations non-portable. The read-modify-write to set values may not do what devices expect, causing unexpected behaviors.

Use of a std::array requires the inclusion of the <array> header using #include <array>.

When C++ is mentioned, often a reference is made to "the Standard". But what is exactly that standard?

C++ has a long history. Started as a small project by Bjarne Stroustrup within Bell Labs, by the early 90's it had become quite popular. Multiple companies were creating C++ compilers so that users could run their C++ compilers on a wide range of computers. But in order to facilitate this, all these competing compilers should share a single definition of the language.

At that point, the C language had successfully been standardized. This means that a formal description of the language was written. This was submitted to the American National Standards Institute (ANSI), which opened up the document for review and subsequently published it in 1989. One year later, the International Organization for Standards (Because it would have different acronyms in different languages they chose one form, ISO, derived from the Greek isos, meaning equal.) adopted the American standard as an International Standard.

For C++, it was clear from the beginning that there was an international interest. A workgroup within ISO was started (known as WG21, within SubCommittee 22). This workgroup drafted a first standard around 1995. But as we programmers know, there's nothing more dangerous to a planned delivery than last minute features, and that happened to C++ as well. In 1995, a cool new library named the STL surfaced, and the people working in WG21 decided to add a slimmed-down version to the C++ draft standard. Naturally, this caused the deadlines to be missed and only 3 years later did the document become final. ISO is a very formal organization, so the C++ Standard was christened with the not very marketable name of ISO/IEC 14882. As standards can be updated, this exact version became known as 14882:1998.

And indeed there was a demand to update the Standard. The Standard is a very thick document, which aims to exactly describe how C++ compilers should work. Even a slight ambiguity can be worth fixing, so by 2003 an update was released as 14882:2003. However, this did not add any feature to C++; the new features were scheduled for the second update.

Informally, this second update was known as C++0x, because it wasn't known whether this would take until 2008 or 2009. Well - that version also got a slight delay, which is why it became 14882:2011.

Luckily, WG21 decided not to let that happen again. C++11 was well-received and let to a renewed interest in C++. So, to keep the momentum, the third update went from planning to publishing in 3 years, to become 14882:2014.

The work didn't stop there, either. The C++17 standard has been proposed and the work for C++20 has been started.

Be aware of problems when declaring multiple pointers on the same line.

int* a, b, c; //Only a is a pointer, the others are regular ints.

int* a, *b, *c; //These are three pointers!

int *foo[2]; //Both *foo[0] and *foo[1] are pointers.

std::atomic allows atomic access to a TriviallyCopyable type, it is implementation-dependent if this is done via atomic operations or by using locks. The only guaranteed lock-free atomic type is std::atomic_flag.

Operators are listed top to bottom, in descending precedence. Operators with the same number have equal precedence and the same associativity.

1. ::
2. The postfix operators: [] () T(...) . -> ++ -- dynamic_cast static_cast reinterpret_cast const_cast typeid
3. The unary prefix operators: ++ -- * & + - ! ~ sizeof new delete delete[]; the C-style cast notation, (T)...; (C++11 and above) sizeof... alignof noexcept
4. .* and ->*
5. *, /, and %, binary arithmetic operators
6. + and -, binary arithmetic operators
7. << and >>
8. <, >, <=, >=
9. == and !=
10. &, the bitwise AND operator
11. ^
12. |
13. &&
14. ||
15. ?: (ternary conditional operator)
16. =, *=, /=, %=, +=, -=, >>=, <<=, &=, ^=, |=
17. throw
18. , (the comma operator)

The assignment, compound assignment, and ternary conditional operators are right-associative. All other binary operators are left-associative.

The rules for the ternary conditional operator are a bit more complicated than simple precedence rules can express.

• An operand binds less tightly to a ? on its left or a : on its right than to any other operator. Effectively, the second operand of the conditional operator is parsed as though it is parenthesized. This allows an expression such as a ? b , c : d to be syntactically valid.
• An operand binds more tightly to a ? on its right than to an assignment operator or throw on its left, so a = b ? c : d is equivalent to a = (b ? c : d) and throw a ? b : c is equivalent to throw (a ? b : c).
• An operand binds more tightly to an assignment operator on its right than to : on its left, so a ? b : c = d is equivalent to a ? b : (c = d).

The constexpr keyword was added in C++11 but for a few years since the C++11 standard was published, not all major compilers supported it. at the time that the C++11 standard was published. As of the time of publication of C++14, all major compilers support constexpr.

The above syntax shows a full function declaration using a trailing type, where square brackets indicate an optional part of the function declaration (like the argument list if a no-arg function).

Additionally, the syntax of the trailing return type prohibits defining a class, union, or enum type inside a trailing return type (note that this is not allowed in a leading return type either). Other than that, types can be spelled the same way after the -> as they would be elsewhere.

• A normal function is never related to a function template, despite same name, same type.
• A normal function call and a generated function template call are different even if they share the same name, same return type and same argument list

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

Type traits are templated constructs used to compare and test the properties of different types at compile time. They can be used to provide conditional logic at compile time that can limit or extend the functionality of your code in a specific manner. The type traits library was brought in with the c++11 standard which provides a number different functionalities. It is also possible to create your own type trait comparison templates.

Variant is a replacement for raw union use. It is type-safe and knows what type it is, and it carefully constructs and destroys the objects within it when it should.

It is almost never empty: only in corner cases where replacing its content throws and it cannot back out safely does it end up being in an empty state.

It behaves somewhat like a std::tuple, and somewhat like an std::optional.

Using std::get and std::get_if is usually a bad idea. The right answer is usually std::visit, which lets you deal with every possibility right there. if constexpr can be used within the visit if you need to branch your behavior, rather than doing a sequence of runtime checks that duplicate what visit will do more efficiently.

The C++ language does not dictate any character-set, some compilers may support the use of UTF-8, or even UTF-16. However there is no certainty that anything beyond simple ANSI/ASCII characters will be provided.

Thus all international language support is implementation defined, reliant on what platform, operating system, and compiler you may be using.

Several third party libraries (such as the International Unicode Committee Library) that can be used to extend the international support of the platform.

What does 'const member functions' of a class really means. The simple definition seems to be that, a const member function cannot change the object. But what does 'can not change' really means here. It simply means that you cannot do an assignment for class data members.

However, you can do other indirect operations like inserting an entry into a map as shown in the example. Allowing this might look like this const function is modifying the object (yes, it does in one sense), but it is allowed.

So, the real meaning is that a const member function cannot do an assignment for the class data variables. But it can do other stuff like explained in the example.

In C++, as in C, the C++ compiler and compilation process makes use of the C preprocessor. As specified by the GNU C Preprocessor manual, a header file is defined as the following:

A header file is a file containing C declarations and macro definitions (see Macros) to be shared between several source files. You request the use of a header file in your program by including it, with the C preprocessing directive ‘#include’.

Header files serve two purposes.

• System header files declare the interfaces to parts of the operating system. You include them in your program to supply the definitions and declarations you need to invoke system calls and libraries.
• Your own header files contain declarations for interfaces between the source files of your program. Each time you have a group of related declarations and macro definitions all or most of which are needed in several different source files, it is a good idea to create a header file for them.

However, to the C preprocessor itself, a header file is no different than a source file.

The header/source file organization scheme is simply a strongly-held and standard convention set by various software projects in order to provide separation between interface and implementation.

Although it is not formally enforced by the C++ Standard itself, following the header/source file convention is highly recommended, and, in practice, is already almost ubiquitous.

Note that header files may be replaced as a project file structure convention by the upcoming feature of modules, which is still to be considered for inclusion in a future C++ Standard as of the time of writing (e.g. C++20).

Default constructor of std::istream_iterator constructs an iterator which represents the end of the stream. Thus, std::copy(std::istream_iterator<int>(ifs), std::istream_iterator<int>(), .... means to copy from the current position in ifs to the end.

In November 2014, the C++ Standardization Committee adopted proposal N3922, which eliminates the special type deduction rule for auto and braced initializers using direct initialization syntax. This is not part of the C++ standard but has been implemented by some compilers.

The class std::any provides a type-safe container to which we can put single values of any type.

Currently, there exists no universal or dominant build system for C++ that is both popular and cross-platform. However, there do exist several major build systems that are attached to major platforms/projects, the most notable being GNU Make with the GNU/Linux operating system and NMAKE with the Visual C++/Visual Studio project system.

Additionally, some Integrated Development Environments (IDEs) also include specialized build systems to be used specifically with the native IDE. Certain build system generators can generate these native IDE build system/project formats, such as CMake for Eclipse and Microsoft Visual Studio 2012.

OpenMP does not require any special headers or libraries as it is a built-in compiler feature. However, if you use any OpenMP API functions such as omp_get_thread_num(), you will need to include omp.h and its library.

OpenMP pragma statements are ignored when the OpenMP option is not enabled during compilation. You may want to refer to the compiler option in your compiler's manual.

• GCC uses -fopenmp
• Clang uses -fopenmp
• MSVC uses /openmp

It is usually better to declare const, & and constexpr whenever you use auto if it is ever required to prevent unwanted behaviors such as copying or mutations. Those additional hints ensures that the compiler does not generate any other forms of inference. It is also not advisible to over use auto and should be used only when the actual declaration is very long, especially with STL templates.

Different styles of C++ have been used in those examples.  Be careful that if you are using a C++98 compiler; some of this code may not be usable.

The standard guarantees the following:

• The alignment requirement of a type is a divisor of its size. For example, a class with size 16 bytes could have an alignment of 1, 2, 4, 8, or 16, but not 32. (If a class's members only total 14 bytes in size, but the class needs to have an alignment requirement of 8, the compiler will insert 2 padding bytes to make the class's size equal to 16.)

• The signed and unsigned versions of an integer type have the same alignment requirement.
• A pointer to void has the same alignment requirement as a pointer to char.
• The cv-qualified and cv-unqualified versions of a type have the same alignment requirement.

Note that while alignment exists in C++03, it was not until C++11 that it became possible to query alignment (using alignof) and control alignment (using alignas).

Adding, removing and moving the elements within the list, or across several lists, does not invalidate the iterators currently referring to other elements in the list. However, an iterator or reference referring to an element is invalidated when the corresponding element is removed (via erase_after) from the list. std::forward_list meets the requirements of Container (except for the size member function and that operator=='s complexity is always linear), AllocatorAwareContainer and SequenceContainer.

This topic ain't complete yet, examples on following techniques/tools would be useful:

• Mention more static analysis tools
• Binary instrumentation tools (like UBSan, TSan, MSan, ESan ...)
• Hardening (CFI ...)
• Fuzzing

As the name goes, the elements in unordered map are not stored in sorted sequence. They are stored according to their hash values and hence, usage of unordered map has many benefits such as it only takes O(1) to search any item from it. It is also faster than other map containers. It is also visible from the example that it is very easy to implement as the operator ( [] ) helps us to directly access the mapped value.

The standard library <iostream> defines few streams for input and output:

|stream | description                      |
|-------|----------------------------------|
|cin    | standard input stream            |
|cout   | standard output stream           |
|cerr   | standard error (output) stream   |
|clog   | standard logging (output) stream |

Out of four streams mentioned above cin is basically used for user input and other three are used for outputting the data. In general or in most coding environments cin (console input or standard input) is keyboard and cout (console output or standard output) is monitor.

cin >> value

cin   - input stream
'>>'  - extraction operator
value - variable (destination)

cin here extracts the input entered by the user and feeds in variable value. The value is extracted only after user presses ENTER key.

cout << "Enter a value: "

cout              - output stream
'<<'              - insertion operator
"Enter a value: " - string to be displayed

cout here takes the string to be displayed and inserts it to standard output or monitor

All four streams are located in standard namespace std so we need to print std::stream for stream stream to use it.

There is also a manipulator std::endl in code. It can be used only with output streams. It inserts end of line '\n' character in the stream and flushes it. It causes immediately producing output.

Manipulators can be used in other way. For example:

1. os.width(n); equals to os << std::setw(n);
is.width(n); equals to is >> std::setw(n);

2. os.precision(n); equals to os << std::setprecision(n);
is.precision(n); equals to is >> std::setprecision(n);

3. os.setfill(c); equals to os << std::setfill(c);

4. str >> std::setbase(base); or str << std::setbase(base); equals to

str.setf(base ==  8 ? std::ios_base::oct :
            base == 10 ? std::ios_base::dec :
                base == 16 ? std::ios_base::hex :
                     std::ios_base::fmtflags(0),
         std::ios_base::basefield);

5. os.setf(std::ios_base::flag); equals to os << std::flag;
is.setf(std::ios_base::flag); equals to is >> std::flag;

os.unsetf(std::ios_base::flag); equals to os << std::no ## flag;
is.unsetf(std::ios_base::flag); equals to is >> std::no ## flag;
   
   (where ## - is concatenation operator)
   
   for next flags: boolalpha, showbase, showpoint, showpos, skipws, uppercase.

6. std::ios_base::basefield.
   For flags: dec, hex and oct:

• os.setf(std::ios_base::flag, std::ios_base::basefield); equals to os << std::flag;
is.setf(std::ios_base::flag, std::ios_base::basefield); equals to is >> std::flag;
  ( 1 )
  
  
• str.unsetf(std::ios_base::flag, std::ios_base::basefield); equals to str.setf(std::ios_base::fmtflags(0), std::ios_base::basefield);
  ( 2 )

7. std::ios_base::adjustfield.
   For flags: left, right and internal:

• os.setf(std::ios_base::flag, std::ios_base::adjustfield); equals to os << std::flag;
is.setf(std::ios_base::flag, std::ios_base::adjustfield); equals to is >> std::flag;
  ( 1 )
  
  
• str.unsetf(std::ios_base::flag, std::ios_base::adjustfield); equals to str.setf(std::ios_base::fmtflags(0), std::ios_base::adjustfield);
  ( 2 )

( 1 ) If flag of corresponding field previously set have already unset by unsetf.
( 2 ) If flag is set.

8. std::ios_base::floatfield.
   

• os.setf(std::ios_base::flag, std::ios_base::floatfield); equals to os << std::flag;
is.setf(std::ios_base::flag, std::ios_base::floatfield); equals to is >> std::flag;
  
  for flags: fixed and scientific.
  
  
• os.setf(std::ios_base::fmtflags(0), std::ios_base::floatfield); equals to os << std::defaultfloat;
is.setf(std::ios_base::fmtflags(0), std::ios_base::floatfield); equals to is >> std::defaultfloat;
  

9. str.setf(std::ios_base::fmtflags(0), std::ios_base::flag); equals to str.unsetf(std::ios_base::flag)
   
   for flags: basefield, adjustfield, floatfield.

10. os.setf(mask) equals to os << setiosflags(mask);
is.setf(mask) equals to is >> setiosflags(mask);

os.unsetf(mask) equals to os << resetiosflags(mask);
is.unsetf(mask) equals to is >> resetiosflags(mask);
    
    For almost all mask of std::ios_base::fmtflags type.