Contents

INTETIONALLY LEFT BLANK.............................................................................................................7

FROM NEXT PAGE STARTING NEW BOOK......................................................................................7
THE MAIN() FUNCTION............................................................................................................................10
main ( )..............................................................................................................................................10
Declaring Variable-Length Parameter Lists.....................................................................................10
DECLARATIONS.....................................................................................................................................12
TYPE.......................................................................................................................................................12
Type classification.............................................................................................................................12
Type naming......................................................................................................................................13
Fundamental types............................................................................................................................13
OBJECT LIFETIME...................................................................................................................................17
NAMESPACE***......................................................................................................................................18
L-VALUE AND R-VALUE REFERENCES***................................................................................................19
POINTERS................................................................................................................................................20
Pointer to a constant variable...........................................................................................................20
Constant pointer to a variable..........................................................................................................20
Constant pointer to a constant variable............................................................................................21
Character array literals....................................................................................................................21
ARRAYS***............................................................................................................................................21
ENUMERATIONS AND ENUMERATORS***................................................................................................24
STORAGE DURATION AND LINKAGE***..................................................................................................25
Storage class specifiers***...............................................................................................................25
Linkage***........................................................................................................................................37
CONSTANTS***.......................................................................................................................................38
MUTABLE: BITWISE VS. LOGICAL CONST................................................................................................40
VOLATILE................................................................................................................................................41
REFERENCES...........................................................................................................................................41
DELTYPE SPECIFIER***...........................................................................................................................42
AUTO SPECIFIER***................................................................................................................................42
ALIGNAS SPECIFIER (SINCE C++ 11)***.................................................................................................42
TYPEDEF SPECIFIER***...........................................................................................................................42
TYPENAME*** (???)..............................................................................................................................42
ELABORATED TYPE SPECIFIER***...........................................................................................................43
STATIC ASSERTION***............................................................................................................................43
ASM DECLARATION***...........................................................................................................................43

DEFINITION............................................................................................................................................44
INITIALIZATION***..............................................................................................................................46
DEFAULT INITIALIZATION***..................................................................................................................46
VALUE INITIALIZATION***.....................................................................................................................46
COPY INITIALIZATION***.......................................................................................................................46
DIRECT INITIALIZATION***....................................................................................................................46
AGGREGRATE INITIALIZATION***..........................................................................................................46
LIST INITIALIZATION (SINCE C++11) ***...............................................................................................46
REFERENCE INITIALIZATION***..............................................................................................................46
STATIC NON LOCAL INITIALIZATION***..................................................................................................47
ZERO INITIALIZATION***........................................................................................................................47
CONSTANT INITIALIZATION***...............................................................................................................47
DYNAMIC NON LOCAL INITIALIZATION***.............................................................................................47
EXPRESSIONS.........................................................................................................................................48

1
 VALUE CATEGORIES...............................................................................................................................48
EXPRESSION PARSER...............................................................................................................................49
OPERATORS.............................................................................................................................................49
Logical operators***........................................................................................................................49
Bitwise operators***........................................................................................................................49
Shift operators...................................................................................................................................50
Write a generic method to convert any unsigned number (int or long) to binary number ???........52
The Conditional operator (ternary operator (?))***.......................................................................52
The Comma Operator***.................................................................................................................53
The Compile-Time Operator sizeof...................................................................................................54
Common operators............................................................................................................................54
Operator Precedence Summary........................................................................................................54
CONVERSIONS.........................................................................................................................................57
CASTING OPERATORS..............................................................................................................................57
C-STYLE CAST.........................................................................................................................................57
C++ EXPLICIT CASTS..............................................................................................................................57
static_cast.........................................................................................................................................58
dynamic_cast.....................................................................................................................................59
const_cast..........................................................................................................................................60
reinterpret_cast.................................................................................................................................60
Run Time Type Identification (RTTI)................................................................................................61
standard conversions***..................................................................................................................62
const_cast conversion.......................................................................................................................62
static_cast conversion.......................................................................................................................62
dynamic_cast conversion..................................................................................................................63
reinterpret_cast conversion...............................................................................................................63
explicit cast conversion....................................................................................................................63
User-defined conversion...................................................................................................................63
NULL-TERMINATED STRINGS***............................................................................................................63
CLASSES...................................................................................................................................................65
ENCAPSULATION.....................................................................................................................................65
ABSTRACTION.........................................................................................................................................65
CLASS TYPES..........................................................................................................................................65
-----------------------------------------------.................................................................................................65
C++ HEADER FILES***...........................................................................................................................66
UNION TYPES..........................................................................................................................................67
CONSTRUCTORS......................................................................................................................................67
Explicit constructor***.....................................................................................................................68
Constructor gotcha***.....................................................................................................................69
Storage allocation for classes...........................................................................................................69
Initialization lists***........................................................................................................................70
DESTRUCTORS........................................................................................................................................71
COPY CONSTRUCTOR???........................................................................................................................71
ASSIGNMENT OPERATOR (COPY ASSIGNMENT OPERATOR) ***..............................................................71
Virtual assignment operator***.......................................................................................................77
COPY CTOR VS ASSIGNMENT OPERATOR................................................................................................84
CANONICAL FORM OF A CLASS...............................................................................................................84
COMPOSITION (CONTAINMENT, AGGREGATION, EMBEDDING, LAYERING)............................................86
FRIENDS..................................................................................................................................................86
Friend functions................................................................................................................................86
Friend classes*** (???)....................................................................................................................87
REDUCING RECOMPILATION***.....................................................................................................89
READ LARGE SCALE C++ SOFTWARE DESIGN.......................................................................................89
???..........................................................................................................................................................89
FUNCTIONS ***......................................................................................................................................90

2
 FUNCTION ARGUMENTS & RETURN VALUES...........................................................................................90
DEFAULT VALUES....................................................................................................................................93
FUNCTION PROTOTYPES..........................................................................................................................94
FUNCTION CALLS***..............................................................................................................................94
RESOLUTION OF FUNCTION CALLS***....................................................................................................94
FUNCTION POINTERS AND CALL BACK TECHNIQUE***..........................................................................95
Function pointers..............................................................................................................................95
Defining a function pointer...............................................................................................................95
 To define a pointer to a function that has no arguments and no return value, you say:.........95
void (*funcPtr)();..............................................................................................................................95
 Complicated examples.............................................................................................................95
//ComplicatedDefinitions.cpp...........................................................................................................95
/* 1. */ void * (*(*fp1)(int))[10];..............................................................................................95
/* 2. */ float (*(*fp2)(int,int,float))(int);...................................................................................95
/* 3. */ typedef double (*(*(*fp3)())[10])();.............................................................................95
fp3 a;.................................................................................................................................................95
/* 4. */ int (*(*f4())[10])();.......................................................................................................95
int main() {}......................................................................................................................................95
Number 1 says “fp1 is a pointer to a function that takes an integer argument and returns a pointer
to an array of 10 void pointers.”......................................................................................................95
Number 2 says “fp2 is a pointer to a function that takes three arguments (int, int, and float) and
returns a pointer to a function that takes an integer argument and returns a float.”......................96
Number 3 says “fp3 is a pointer to a function that takes no arguments and returns a pointer to an
array of 10 pointers to functions that take no arguments and return doubles.”...............................96
Number 4 is a function declaration instead of a variable definition. It says “f4 is a function that
returns a pointer to an array of 10 pointers to functions that return integers.”..............................96
Call back technique...........................................................................................................................99
Using Polymorphism and Virtual Functions Instead of Function Pointers***..............................100
FUNCTION OVERLOADING.....................................................................................................................101
Finding the Address of an Overloaded Function*** (???)............................................................102
FUNCTION OVERRIDING........................................................................................................................102
FUNCTION OVERLOADING VS. OVERRIDING.........................................................................................103
OPERATOR OVERLOADING.............................................................................................................103
WHICH OPERATORS CANNOT BE OVERLOADED AND WHY....................................................................103
RESTRICTIONS.......................................................................................................................................103
WHY FRIENDS IN OPERATOR OVERLOADING.........................................................................................104
OVERLOADING INSERTION AND EXTRACTION OPERATORS (<< AND >>)..............................................106
OVERLOADING SUBSCRIPT OPERATOR..................................................................................................106
OVERLOADING FUNCTION CALL OPERATOR***....................................................................................106
TYPE CONVERSION OPERATORS***......................................................................................................107
INHERITANCE & COMPOSITION***.............................................................................................109
PUBLIC, PRIVATE AND PROTECTED INHERITANCE..................................................................................112
Public inheritance...........................................................................................................................112
Protected inheritance......................................................................................................................113
Private inheritance..........................................................................................................................113
MULTILEVEL AND MULTIPLE INHERITANCES.........................................................................................114
Multlevel Inheritance......................................................................................................................114
Multiple Inheritance........................................................................................................................115
Virtual inheritance***.....................................................................................................................116
Virtual functions..............................................................................................................................117
TEMPLATES..........................................................................................................................................117
EXPLICIT INITIALIZATION FOR FUNDAMENTAL TYPES..........................................................................118
TEMPLATE PARAMETERS AND TEMPLATE ARGUMENTS.........................................................................118
Non-type template parameters/arguments......................................................................................119

3
 Template type arguments.................................................................................................................122
Template template arguments.........................................................................................................122
Default argument for template parameter......................................................................................123
CLASS TEMPLATES................................................................................................................................124
Template Static Data Member.........................................................................................................125
Using Non-type (standard) parameters..........................................................................................126
Using Default arguments with template classes.............................................................................126
Nested Template Classes.................................................................................................................127
Class template deduction***..........................................................................................................127
FUNCTION TEMPLATE............................................................................................................................127
Instantiation of function template...................................................................................................127
Template argument deduction.........................................................................................................129
Explicit template arguments............................................................................................................129
Template argument substitution......................................................................................................130
Function template specialization???..............................................................................................131
Function template overloading???.................................................................................................132
CLASS MEMBER TEMPLATE..................................................................................................................134
Member function templates.............................................................................................................135
Conversion function templates (Templates and automatic type conversions)................................137
Member variable template..............................................................................................................140
Template constructors.....................................................................................................................141
TEMPLATE SPECIALIZATION..................................................................................................................143
Explicit (full) template specialization.............................................................................................143
Partial template specialization.......................................................................................................148
FUNCTION TEMPLATE OVERLOADING AND SPECIALIZATION EXAMPLES..............................................153
FRIEND AND TEMPLATES.......................................................................................................................154
Templates friends............................................................................................................................154
Template friend operators...............................................................................................................156
TEMPLATES AND MULTIPLE-FILE PROJECTS..........................................................................................158
EXCEPTION HANDLING....................................................................................................................158
FUNDAMENTALS...................................................................................................................................159
WHAT TO THROW..................................................................................................................................159
WHAT TO CATCH...................................................................................................................................160
CATCH THROUGH INHERITANCE............................................................................................................160
EXCEPTION SPECIFICATION...................................................................................................................161
STACK UNWINDING..............................................................................................................................161
EXCEPTION THROWN FROM CONSTRUCTOR AND DESTRUCTOR...........................................................162
INSUFFICIENT MEMORY WHEN USING NEW..........................................................................................163
STANDARD LIBRARY EXCEPTION HIERARCHY.....................................................................................163
MFC WAY OF EXCEPTION HANDLING***..............................................................................................165
INPUT/OUTPUT USING STREAM CLASSES (WORK ON REDUCING THE MATERIAL)...166
STANDARD FUNCTION LIBRARY...................................................................................................167
THE C-BASED I/O FUNCTIONS.............................................................................................................167
STRING AND CHARACTER FUNCTIONS..................................................................................................167
MATHEMATICAL FUNCTIONS.................................................................................................................167
TIME DATE AND LOCALIZATION FUNCTIONS........................................................................................167
DYNAMIC ALLOCATION FUNCTIONS.....................................................................................................167
(ONLY DYNAMIC MEMORY MANAGEMENT)..........................................................................................167
UTILITY FUNCTIONS.............................................................................................................................167
WIDE-CHARACTER FUNCTIONS............................................................................................................167
The Wide-Character Classification Functions................................................................................167
The Wide-Character I/O Functions................................................................................................167
SPECIAL TOPICS..................................................................................................................................168
C++ CODING STYLE IDIOMS???...........................................................................................................168

4
 RAII: Resource Acquisition Is Initialization...................................................................................168
Copy-swap Idiom............................................................................................................................168
CRTP: Curiously Recurring Template Pattern...............................................................................168
pImpl: Pointer-to-Implementation..................................................................................................168
Compile-time polymorphism...........................................................................................................168
Template and Hook.........................................................................................................................168
THE PROBLEM WITH CONST DATA MEMBERS???.................................................................................168
CLONING C++ CLASS WITH PURE VIRTUAL METHODS..........................................................................168
MEMCPY IS EVIL....................................................................................................................................169
USING THE ASM KEYWORD???.............................................................................................................170
LINKAGE SPECIFICATION****MOVE FROM HERE***..........................................................................170
External linkage..............................................................................................................................170
Internal linkage...............................................................................................................................170
No linkage.......................................................................................................................................171
ARRAY-BASED I/O???..........................................................................................................................171
AUTO_PTRS...........................................................................................................................................171
PROXY CLASSES (SURROGATES)???......................................................................................................180
REFERENCE COUNTING???....................................................................................................................182
SOFTWARE ENGINEERING WITH INHERITANCE.....................................................................183
FINALLY SOME IMPORTANT POINTS...........................................................................................183
PREPROCESSOR..................................................................................................................................184
PREPROCESSOR MACROS (#DEFINE, #UNDEF).......................................................................................184
FUNCTION MACROS...............................................................................................................................184
CONDITIONAL INCLUSIONS (#IFDEF, #IFNDEF, #IF, #ENDIF, #ELSE AND #ELIF)....................................185
CONDITIONAL COMPILATION................................................................................................................186
LINE CONTROL (#LINE)........................................................................................................................186
ERROR DIRECTIVE (#ERROR)................................................................................................................186
SOURCE FILE INCLUSION (#INCLUDE)***.............................................................................................187
PRAGMA DIRECTIVE (#PRAGMA)..........................................................................................................188
PREDEFINED MACRO NAMES.................................................................................................................188
WHY ARE PREPROCESSOR MACROS EVIL..............................................................................................190
PREPROCESSOR PITFALLS***................................................................................................................190
???...................................................................................................................................................190
INLINE FUNCTIONS................................................................................................................................190
MACRO VS INLINE FUNCTIONS.............................................................................................................191
THE C ASSERT( ) MACRO......................................................................................................................192
NICE C++ FAQS.....................................................................................................................................194
Why doesn't overloading work for derived classes?.......................................................................194
Is there a "placement delete"?........................................................................................................195
Why can't I define constraints for my template parameters?.........................................................196
Why can't I assign a vector<Apple*> to a vector<Fruit*>?.........................................................198
How do I read a string from input?................................................................................................199
Why can't I overload dot, ::, sizeof, etc.?........................................................................................199
How do I convert an integer to a string?........................................................................................200
How do I call a C function from C++?..........................................................................................201
Should I put "const" before or after the type?................................................................................202
What good is static_cast?...............................................................................................................202
So, what's wrong with using macros?.............................................................................................203
Is there is any reason to make the permissions on an overridden C++ virtual function different
from the base class? Is there any danger in doing so?...................................................................204
What happens when you make call "delete this?............................................................................205
How virtual functions are implemented C++?...............................................................................206
Can you think of a situation where your program would crash without reaching the breakpoint
which you set at the beginning of main()?......................................................................................206

5
 What does extern "C" int func(int *, Foo) accomplish?.................................................................206
What are storage qualifiers in C++?.............................................................................................206
MORE NICE C++ FAQS (FROM C++ FAQS BOOK - MARSHALL CLINE)...............................208
???........................................................................................................................................................208
BRAINBENCH LIKE QUESTIONS....................................................................................................209
EXTERN.................................................................................................................................................209
DECLARATION.......................................................................................................................................209
SCOPE EXCEPTION................................................................................................................................210
SCOPE-IF...............................................................................................................................................210
CLASS SCOPE........................................................................................................................................211
ENUM DECLARATIONS...........................................................................................................................212
NAMESPACE LOOKUP............................................................................................................................213
LINKAGE...............................................................................................................................................213
STATIC STORAGE...................................................................................................................................214
STANDARD CONVERSIONS....................................................................................................................214
TEMPORARIES.......................................................................................................................................215
CASTS...................................................................................................................................................215
DELETE..................................................................................................................................................216
POINTERS COMPARISON........................................................................................................................217
CONDITIONAL OPERATOR......................................................................................................................217
ARRAY DECLARATION...........................................................................................................................218
OVERLOADING......................................................................................................................................218
DEFAULT ARGUMENT............................................................................................................................218
INITIALIZATION.....................................................................................................................................220
VIRTUAL FUNCTIONS............................................................................................................................221
ACCESS CONTROL................................................................................................................................223
USER DEFINED CONVERSIONS...............................................................................................................223
MEMBER INITIALIZATION......................................................................................................................223
COPYING OBJECTS................................................................................................................................224
FUNCTION OVERLOADING....................................................................................................................225
MEMBER TEMPLATES............................................................................................................................226
VALID DECLARATION FOR MAIN...........................................................................................................227
EXERCISES............................................................................................................................................228
FROM “C++ ESSENTIALS”???...............................................................................................................228
FROM “THINKING IN C++ VOLUME 1”???...........................................................................................228
From “Thinking in C++ Volume 2”???................................................................................................228

6
Intetionally left blank

From Next Page starting new book

7
8
9
Basics Concepts

The main() function

main ( )
 Below operations are performed before the main function is called at program
startup
 Parse GetCommandLine() to argc and argv
 Standard C Library initialization
 C++ Constructor of global variables
The above execution may be different on different platforms and therefore it may
not be safe to call standard C functions inside C++ constructor of global variables

 The main () function returns an integer to the calling process, which is generally the
operating system. Returning a value from main () is the equivalent of calling exit ()
with the same value.
 If main () does not explicitly return a value, the value passed to the calling process
is technically undefined. In practice, most C/C++ compilers automatically return 0,
but do not rely on this if portability is a concern.

 C and C++ have a special argument list for main( ), which looks like this:

int main(int argc, char* argv[]) OR

int main(int argc, char** argv)

The first argument is the number of elements in the array, which is the second
argument. The second argument is always an array of char*, because the arguments
are passed from the command line as character arrays. Each whitespace-delimited
cluster of characters on the command line is turned into a separate array argument.
The following program prints out all its command-line arguments by stepping
through the array:

//CommandLineArgs.cpp
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
cout << "argc = " << argc << endl;
for(int i = 0; i < argc; i++)
cout << "argv[" << i << "] = "
<< argv[i] << endl;
}

 All you get from the command-line is character arrays; if you want to treat an
argument as some other type, you are responsible for converting it inside your
program.

10
 To facilitate the conversion to numbers, there are some helper functions in the
Standard C library, declared in <cstdlib>. The simplest ones to use are atoi( ),
atol( ), and atof( ) to convert an ASCII character array to an int, long, and double
floating-point value, respectively.

Declaring Variable-Length Parameter Lists

Example
/* va_arg example */
#include <stdio.h> /* printf */
#include <stdarg.h> /* va_list, va_start, va_arg, va_end */

int FindMax (int n, ...)

{
int i,val,largest;
va_list vl;
va_start(vl,n);
largest=va_arg(vl,int);
for (i=1;i<n;i++)
{
val=va_arg(vl,int);
largest=(largest>val)?largest:val;
}
va_end(vl);
return largest;
}

int main ()
{
int m;
m= FindMax (7,702,422,631,834,892,104,772);
printf ("The largest value is: %d\n",m);
return 0;
}

11
Declarations
 A declaration introduces a name – an identifier – to the compiler
 Declaration indicates type
 Can be repeated (one exception)

Type
 Objects, references, functions including function template specializations, and
expressions have a property called type, which both restricts the operations that are
permitted for those entities and provides semantic meaning to the otherwise generic
sequences of bits.
 Data types define the way you use storage (memory) in the programs you write.
 By specifying a data type, you tell the compiler how to create a particular piece of
storage, and also how to manipulate that storage

Type classification
 fundamental types (see also std::is_fundamental):
 the type void (see also std::is_void);
 the type std::nullptr_t (since C++11) (see also std::is_null_pointer);
 arithmetic types (see also std::is_arithmetic):
 floating-point types (float, double, long double) (see also
std::is_floating_point);
 integral types (see also std::is_integral):
 the type bool;
 character types:
 narrow character types (char, signed char, unsigned char);
 wide character types (char16_t, char32_t, wchar_t);
 signed integer types (short int, int, long int, long long int);
 unsigned integer types (unsigned short int, unsigned int, unsigned long int,
unsigned long long int);
 compound types (see also std::is_compound):
 reference types (see also std::is_reference):
i. lvalue reference types (see also std::is_lvalue_reference):
1. lvalue reference to object types;
2. lvalue reference to function types;
ii. rvalue reference types (see also std::is_rvalue_reference):
1. rvalue reference to object types;
2. rvalue reference to function types;
 pointer types (see also std::is_pointer):
i. pointer to object types;
ii. pointer to function types;
 pointer to member types (see also std::is_member_pointer):
i. pointer to data member types (see also
std::is_member_object_pointer);
ii. pointer to member function types (see also
std::is_member_function_pointer);
 array types (see also std::is_array);
12
  function types (see also std::is_function);
 enumeration types (see also std::is_enum);
 class types:
i. non-union types (see also std::is_class);
ii. union types (see also std::is_union).

 For every type other than reference and function, the type system supports three
additional cv-qualified versions of that type (const, volatile, and const volatile).
 Types are grouped in various categories based on their properties:
 object types: any (possibly cv-qualified) type other than function, reference,
or void types: arithmetic, pointer, pointer to member, array, enumeration,
class, and std::nullptr_t types (that is, a type that an object may have) (see
also std::is_object);
 scalar types: (possibly cv-qualified) arithmetic, pointer, pointer to member,
enumeration, and std::nullptr_ttypes (see also std::is_scalar);
 trivial types (see also std::is_trivial), POD types (see also std::is_pod), literal
types (see also std::is_literal_type), and other categories listed in the the
type traits library or as named type requirements.

Type naming
 A name can be declared to refer to a type by means of:
 class declaration;
 enum declaration;
 typedef declaration;
 type alias declaration.

 Example:

Fundamental types
 A built-in data type is one that the compiler intrinsically understands.

13
 C++ doesn’t say how many bits each of the built-in types must contain. Instead, it
stipulates the minimum and maximum values that the built-in type must be able to
hold. When a machine is based on binary, this maximum value can be directly
translated into a minimum number of bits necessary to hold that value.
 The minimum and maximum values that can be stored in the various data types are
defined in the system header files limits.h and float.h (in C++ you will generally
#include <climits> and <cfloat> instead).
 C++ have these basic built-in data types
 void : - type with an empty set of values. It is an incomplete type that cannot
be completed (consequently, objects of type void are disallowed). There are
no arrays of void, nor references to void. However, pointers to void and
functions returning type void (procedures in other languages) are permitted.
 std::nullptr_t:- std::nullptr_t is the type of the null pointer literal, nullptr. It is
a distinct type that is not itself a pointer type or a pointer to member type.

 bool :- bool type is capable of holding one of the two values: true or false.
The value of sizeof(bool) is implementation defined and might differ from
1.
 Character types
i. signed char - type for signed character representation.
ii. unsigned char - type for unsigned character representation. Also used
to inspect object representations (raw memory).
iii. char - type for character representation which can be most efficiently
processed on the target system (has the same representation and
alignment as either signed char or unsigned char, but is always a
distinct type). Multibyte characters strings use this type to represent
code units. The character types are large enough to represent 256
different values (in order to be suitable for storing UTF-8 encoded
data) (since C++14)
iv. wchar_t - type for wide character representation (see wide strings).
Required to be large enough to represent any supported character
code unit (32 bits on systems that support Unicode. A notable
exception is Windows, where wchar_t is 16 bits) It has the same size,
signedness, and alignment as one of the integral types, but is a
distinct type.
v. char16_t - type for UTF-16 character representation, required to be
large enough to represent any UTF-16 code unit (16 bits). It has the
same size, signedness, and alignment as std::uint_least16_t, but is a
distinct type.
vi. char32_t - type for UTF-32 character representation, required to be
large enough to represent any UTF-32 code unit (32 bits). It has the
same size, signedness, and alignment as std::uint_least32_t, but is a
distinct type.
 int – Its basic integer type. The keyword int may be omitted if any of the
modifiers listed below are used. If no length modifiers are present, it's
guaranteed to have a width of at least 16 bits. However, on 32/64 bit systems

14
 it is almost exclusively guaranteed to have width of at least 32 bits (see
below).
Modifiers: - modifies the integer type. Can be mixed in any order. Only one
of each group can be present in type name.
i. signed - target type will have signed representation (this is the
default if omitted)
ii. unsigned - target type will have unsigned representation
iii. short - target type will be optimized for space and will have width of
at least 16 bits.
iv. long - target type will have width of at least 32 bits.
v. long long - target type will have width of at least 64 bits.

Note: as with all type specifiers, any order is permitted: unsigned long long
int and long int unsigned long name the same type.
 Floating point types
i. float - single precision floating point type. Usually IEEE-754 32 bit
floating point type
ii. double - double precision floating point type. Usually IEEE-754 64
bit floating point type
iii. long double - extended precision floating point type. Does not
necessarily map to types mandated by IEEE-754. Usually 80-bit x87
floating point type on x86 and x86-64 architectures.
Floating-point types may support special values:
i. infinity (positive and negative), see INFINITY
ii. the negative zero, -0.0. It compares equal to the positive zero, but
is meaningful in some arithmetic operations,
e.g. 1.0/0.0 == INFINITY, but 1.0/-0.0 == -INFINITY), and for
some mathematical functions, e.g. sqrt(std::complex)
iii. not-a-number (NaN), which does not compare equal with anything
(including itself). Multiple bit patterns represent NaNs,
see std::nan, NAN. Note that C++ takes no special notice of
signalling NaNs other than detecting their support
by std::numeric_limits::has_signaling_NaN, and treats all NaNs as
quiet.

15
 Besides the minimal bit counts, the C++ Standard guarantees that

Note: this allows the extreme case in which bytes are sized 64 bits, all types
(including char) are 64 bits wide, and sizeof returns 1 for every type

Range of values

16
Object Lifetime
 Lifetime of an object is equal to or is nested within the lifetime of its storage. See
 Lifetime of a reference is exactly its storage duration.
 The lifetime of a reference begins when its initialization is complete and ends as if
it were a scalar object.
 Note that the lifetime of the referred object may end before the end of the lifetime
of the reference, which makes dangling references possible.
 Lifetimes of member objects and base subobjects begin and end following
Initialization lists***.
 Temporary objects are created when a prvalue is materialized so that it can be used
as a glvalue, which occurs in the following situations:
 binding a reference to a prvalue
 returning a prvalue from a function
 conversion that creates a prvalue
 lambda expression, (since C++11)
 copy-initialization that requires conversion of the initializer,
 list-initialization that constructs an std::initializer_list, (since C++11)
 Reference-initialization to a different but convertible type or to a bitfield.
 (until C++17)
 when initializing an object of type std::initializer_list<T> from a braced-
init-list

17
  when performing member access on a class prvalue
 when performing an array-to-pointer conversion or subscripting on an array
prvalue
 for unevaluated operands in sizeof and typeid
 when a prvalue appears as a discarded-value expression
 if supported by the implementation, when passing or returning an object of
trivially-copyable type in a function call expression (this models passing
structs in CPU registers)
 All temporary objects are destroyed as the last step in evaluating the full-
expression that (lexically) contains the point where they were created, and if
multiple temporary objects were created, they are destroyed in the order
opposite to the order of creation. This is true even if that evaluation ends in
throwing an exception. There are two exceptions from that:
 The lifetime of a temporary object may be extended by binding to a const
lvalue reference or to an rvalue reference (since C++11), see reference
initialization for details.
 The lifetime of a temporary object created when evaluating the default
arguments of a default constructor used to initialize an element of an array
ends before the next element of the array begins initialization.

Namespace***
http://en.cppreference.com/w/cpp/language/namespace

 Namespaces provide a method for preventing name conflicts in large projects.

 A namespace definition can appear only at global scope, or nested within another
namespace.
 No terminating semicolon is necessary after the closing brace of a namespace
definition.
 A namespace definition can be “continued” over multiple header files using a
syntax that, for a class, would appear to be a redefinition
 A namespace name can be aliased to another name, so you don’t have to type an
unwieldy name created by a library vendor. For example

namespace Bob = BobsSuperDuperLibrary;

 You cannot create an instance of a namespace as you can with a class.

 Each translation unit contains an unnamed namespace that you can add to by saying
“namespace” without an identifier. The names in this space are automatically
available in that translation unit without qualification. It is guaranteed that
anunnamed space is unique for each translation unit. If you put local names in an
unnamed namespace, you don’t need to give them internal linkage by making them
static.
 You can refer to a name within a namespace in three ways
o Scope resolution operator
o The using directive
using namespace <NamespaceName>
o The using declaration

18
 using <NamespaceName>::<typeName>
 Example:
//UsingDeclaration.h
#ifndef USINGDECLARATION_H
#define USINGDECLARATION_H
namespace U
{
inline void f() {}
inline void g() {}
}
namespace V
{
inline void f() {}
inline void g() {}
}
#endif // USINGDECLARATION_H ///:~
//UsingDeclaration1.cpp
#include "UsingDeclaration.h"
void h()
{
using namespace U; // Using directive
using V::f; // Using declaration
f(); // Calls V::f();
U::f(); // Must fully qualify to call
}
int main() {}

l-value and r-value references***

http://en.cppreference.com/w/cpp/language/reference

 Left and right with respect to assignment operator.

 An rvalue is any constant, variable, or expression that can produce a value, but an
lvalue must be a distinct, named variable (that is, there must be a physical space in
which to store data)
 Example:-
a += b //lvalue
++a //lvalue as it results in an itself.
a++ //rvalue as it results is in a temp loc

3+4 //rvalue
a+b //rvalue
a++ //rvalue
a=b //OK
(a = b) = 111 //OK in C++ but not in 'C'

 More Examples: -
++++a; //OK as it results in ++(++a); which means ++a is becoming
//an lvalue which is perfectly fine

19
 a++++; //NO as it results in (a++)++ which means a++ is becoming
//an lvalue which is not allowed

Pointers

Pointer to a constant variable

You can’t assign the address of a const object to a non-const pointer because then
you’re saying you might change the object via the pointer.
Of course, you can always use a cast to force such an assignment, but this is bad
programming practice because you are then breaking the constness of the object, along
with any safety promised by the const. For example:
const int x = 10;
int* p = &x; //Error

const int x = 10;

const int* p = &x; //OK

const int x = 10;

int* p = (int*)&x; //LEGAL but bad practice

 In this scenario
 The value of x can neither be changed using its name nor using p.
(x = 20; *p = 20;) //Error
 As pointer is not constant so p can be used to point to some other constant
variable.
(const int y = 10; p = &y;) //OK

 A Pointer to a constant variable can be set to point to a variable. It’s because

we can look upon a variable as a const but the reverse is not possible.
int a(10), b(20);
const int *p(&a); //Pointer to a const

*p = 111; //Error
a = 111; //OK

Constant pointer to a variable

 Example
(int x = 10; int* const p(&x);) //OK
 In this scenario
 The value of x can be changed by using either its name or p.
(x = 20; *p = 20;) //OK
 As pointer is constant so p cannot be used to point to some other variable.
(int y = 10; p = &y;) //Error

20
Constant pointer to a constant variable
 Example
(const int x = 10; const int* const p(&x);)
 In this scenario
 The value of x can neither be changed using its name nor using p.
 Also p can not be used to point to some other const variable.
 A Constant pointer has to be initialized
Example
int* const q; //Error
int x(30), y(40);

int* const q(&x); //OK

Character array literals

The place where strict constness is not enforced is with character array literals. You can
say
char* cp = "howdy";
And the compiler will accept it without complaint. This is technically an error because
a character array literal (“howdy” in this case) is created by the compiler as a constant
character array, and the result of the quoted character array is its starting address in
memory. Modifying any of the characters in the array is a runtime error, although
not all compilers enforce this correctly. So character array literals are actually
constant character arrays. Of course, the compiler lets you get away with treating them
as nonconst because there’s so much existing C code that relies on this.
However, if you try to change the values in a character array literal, the behavior is
undefined, although it will probably work on many machines.
char *x = "howdy"; //OK
x[3] = 'b'; //LEGAL for Compiler but undefined behavior

If you want to be able to modify the string, put it in an array:

char cp[] = "howdy";

Arrays***
 The identifier of an array is unlike the identifiers for ordinary variables. For one
thing, an array identifier is not an lvalue; you cannot assign to it. So one way to
look at the array identifier is as a read-only pointer to the beginning of an array.
 If you declare an array as a function argument, what you’re really declaring is a
pointer so the below two declaration of func1 and func2 are identical

void func1(int a[], int size)

void func2(int* a, int size)

 Array Initialization (Which index can be skipped while initializing multi-

dimensional arrays)

21
 The following is from section A8.7 of "The C Programming Language" by
K&R, 2nd edition, pages 219,220
An aggregate is a structure or array. If an aggregate contains members of aggregate
type, the initialization rules apply recursively. Braces may be elided in the
initialization as follows: if the initializer for an aggregate's member that is itself
an aggregate begins with a left brace, then the succeeding comma-separated list
of initializers initialize the members of the sub aggregate; it is erroneous for there
to be more initializers than members. If, however, the initializer for a sub
aggregate does not begin with a left brace, then only enough elements from the
list are taken to account of the members of the sub aggregate; any remaining
members are left to initialize the next member of the aggregate of which the sub
aggregate is a part. For example,

int x[] = { 1, 3, 5 };
Declares and initializes x as a 1-dimensional array with thee members, since no size
was specified and there are three initializers.

Therefore, given this line

int myArray[][2] = { { 2 }, { 4, 5 }, { 4, 1 } };
The compiler will recursively initialize the array, noting that each sub array starts
with a left brace and has no more than the required number of initializers, and will
count the number of sub arrays to determine the first dimension of the array.

The following is from section A8.7 of "The C Programming Language" by

K&R, 2nd edition, page 220
float y[4][3] = {
{ 1, 3, 5 },
{ 2, 4, 6 },
{ 3, 5, 7 }
};
Is equivalent to
float y[4][3] = {
1, 3, 5, 2, 4, 6, 3, 5, 7
};
Note that in both cases, the fourth row of the array will be initialized with zero,
since not enough initializers were specified.

float y[4][3] = {
{ 1 }, { 2 }, { 3 }, { 4 }
};
Initializes the first column of y and leaves the rest 0.
So the compiler doesn't ignore the inner braces. However, the inner braces are
optional if you specify all of the initializers in order with no gaps. Using the inner
braces gives you more control over the initialization, if you don't want to specify a
full set of initializers.

 C++: multidimensional array initialization in constructor

class A

22
{
public:
int a[2][2];
A();
};

A::A()
{
a = {{1,2},{2,4}};
}
yields: error: assigning to an array from an initializer list

class A
{
public:
int a[2][2];
A();
};

A::A()
{
int b[2][2] = {{1,2},{2,4}};
a = b;
}
yields: invalid array assignment

class A
{
public:
int **a;
A();
};

A::A()
{
int b[2][2] = {{1,2},{2,4}};
a = b;
}
yields: cannot convert ‘int [2][2]’ to ‘int**’ in assignment

Try this, it works for bidimensional array (in standard C++):

class A
{
public:
int a[2][2];
A();

23
 };

typedef struct{ int a[4]; } array_t;

A::A()
{
int at[2][2] = {{1,2},{2,4}};
*(array_t*)a = *(array_t*)at;
}

Enumerations and enumerators***

http://en.cppreference.com/w/cpp/language/enum

 An enumerated data type is a way of attaching names to numbers, thereby giving

more meaning to anyone reading the code.
 enum declarations
 There are two kinds of enum type declarations. One kind creates a named type,
as in
enum Color { Black, Blue, Green, Cyan, Red, Magenta, Brown, White};
enum MyEnumType { ALPHA, BETA, GAMMA };

We can always use “Black” instead of 0, but the compiler will just treat “Black”
as 0; Now “Color” is a user-defined type.
 If you give an enum type a name, you can use that type for variables, function
arguments and return values, and so on:
enum MyEnumType x; //legal in both C and C++
MyEnumType y; // legal only in C++

If( y == ALPHA) //legal

{
…
}
 The other kind creates an unnamed type. This is used when you want names for
constants but don't plan to use the type to declare variables, functions or
arguments, etc. For example, you can write
enum { HOMER, MARGE, BART, LISA, MAGGIE };
 Values of enum constants
 If you don't specify values for enum constants, the values start at zero and
increase by one with each move down the list.
Example:
enum MyEnumType { ALPHA, BETA, GAMMA };
ALPHA has a value of 0, BETA has a value of 1, and GAMMA has a value
of 2.
OR specify the values
enum FooSize { SMALL = 10, MEDIUM = 100, LARGE = 1000 };
 C++ enum type conversion rules
 There is an implicit conversion from any enum type to int.

24
 Example:
enum MyEnumType { ALPHA, BETA, GAMMA };
int i = BETA; // give i a value of 1
int j = 3 + GAMMA; // give j a value of 5

 On the other hand, there is not an implicit conversion from int to an enum type:
MyEnumType x = 2; //should NOT be allowed by compiler
MyEnumType y = 123; //should NOT be allowed by compiler

 In addition, there’s stricter type checking for enumerations in C++. If you have
an instance of an enumeration color called a. You can’t say a++. This is because
incrementing an enumeration is performing two type conversions, one of them
legal in C++ and one of them illegal

Storage duration and linkage***

http://en.cppreference.com/w/cpp/language/storage_duration
http://en.cppreference.com/w/cpp/language/language_linkage

Storage class specifiers***

 When creating a variable, you have a number of options to specify the lifetime of
the variable, how the storage is allocated for that variable, and how the variable is
treated by the compiler.
 Storage class specifiers, together with the scope of the name control two
independent properties of the name: Its storage duration and its linkage
 Below are the storage classs specifiers:-
 auto - automatic storage duration. (until C++11)
 register - automatic storage duration. Also hints to the compiler to place the
object in the processor's register. (deprecated) (until C++17)
 static - static or thread storage duration and internal linkage
 extern - static or thread storage duration and external linkage
 thread_local - thread storage duration. (since C++11)
 Only one storage class specifier may appear in a declaration except that
thread_local may be combined with static or with extern (since C++11)

Local (auto) variables

 Local variables occur within a scope; they are “local” to a function.
 They are often called automatic variables because they automatically come into
being when the scope is entered and automatically go away when the scope closes.
The keyword auto makes this explicit, but local variables default to auto so it is
never necessary to declare something as an auto.

Register variables
 A register variable is a type of local variable.

25
 The register keyword tells the compiler “Make accesses to this variable as fast as
possible.”
 Increasing the access speed is implementation dependent, but, as the name suggests,
it is often done by placing the variable in a register. There is no guarantee that the
variable will be placed in a register or even that the access speed will increase. It is
a hint to the compiler.
 There are restrictions to the use of register variables
 You cannot take or compute the address of a register variable.
 A register variable can be declared only within a block (you cannot have
global or static register variables).
 You can, however, use a register variable as a formal argument in a function
 In general, you shouldn’t try to second-guess the compiler’s optimizer, since
it will probably do a better job than you can. Thus, the register keyword is
best avoided.

Static***
 Variables defined local to a function disappear at the end of the function scope.
When you call the function again, storage for the variables is created a new and the
values are re-initialized. If you want a value to be extant throughout the life of a
program, you can define a function’s local variable to be static and give it an initial
value.
 The initialization is performed only the first time the function is called, and the data
retains its value between function calls. If you do not provide an initializer for a
static variable of a built-in type, the compiler guarantees that variable will be
initialized to zero
The rules are the same for static objects of user-defined types, including the fact
that some initialization is required for the object. If you don’t specify constructor
arguments when you define the static object, the class must have a default
constructor. For example
//StaticObjectsInFunctions.cpp
#include <iostream>
using namespace std;
class X
{
int i;
public:
X(int ii = 0) : i(ii) {} // Default
~X() { cout << "X::~X()" << endl; }
};
void f()
{
static X x1(47);
static X x2; // Default constructor required
}
int main()
{
f();

26
 }
The construction of static object of X inside function f() occurs the first time
control passes through the definition, and only the first time.
 Unlike global variable a static variable unavailable outside the scope of the
function, so it can’t be inadvertently changed. This localizes errors.
 Static object destructors:
 Destructors for static objects (that is, all objects with static storage, not just
local static objects) are called when main( ) exits or when the Standard C
library function exit1( )is explicitly called. Static object destructors are not
called if you exit the program using the Standard C library function abort( ).
 Like ordinary destruction, destruction of static objects occurs in the reverse
order of initialization. However, only objects that have been constructed are
destroyed.
 The C++ development tools keep track of initialization order and the objects
that have been constructed. Global objects are always constructed before
main( ) is entered and destroyed as main( ) exits, but if a function containing
a local static object is never called, the constructor for that object is never
executed, so the destructor is also not executed.
 When static is applied to a function name or to a variable that is outside of all
functions, it means “This name is unavailable outside of this file.” The function
name or variable is local to the file; we say it has file scope. As a demonstration,
compiling and linking the following two files will cause a linker error:
//FileStatic.cpp
// File scope demonstration. Compiling and linking this file with FileStatic2.cpp
// will cause a linker error
// File scope means only available in this file:
static int fs;
int main()
{
fs = 1;
}
//FileStatic2.cpp {O}
//Trying to reference fs
extern int fs;
void func()
{
fs = 100;
}
Even though the variable fs is claimed to exist as an extern in the FileStatic2.cpp,
the linker won’t find it because it has been declared static in FileStatic.cpp.
 Ordinarily, any name at file scope (that is, not nested inside a class or function) is
visible throughout all translation units in a program. This is often called external

1
In most implementations, main( ) just calls exit( ) when it terminates. This means that it can be
dangerous to call exit( ) inside a destructor because you can end up with infinite recursion.
You can specify actions to take place when leaving main( ) (or calling exit( )) by using the Standard C
library function atexit( ). In this case, the functions registered by atexit( )may be called before the
destructors for any objects constructed before leaving main( ) (or calling exit( ))

27
 linkage because at link time the name is visible to the linker everywhere, external to
that translation unit.
 Global variables and ordinary functions have external linkage. There are times
when you’d like to limit the visibility of a name. You might like to have a variable
at file scope so all the functions in that file can use it, but you don’t want functions
outside that file to see or access that variable, or to inadvertently cause name
clashes with identifiers outside the file. An object or function name at file scope that
is explicitly declared static is local to its translation unit. That name has internal
linkage. This means that you can use the same name in other translation units
without a name clash.
 One advantage to internal linkage is that the name can be placed in a header file
without worrying that there will be a clash at link time. Names that are commonly
placed in header files, such as const definitions and inline functions, default to
internal linkage
 Note that linkage refers only to elements that have addresses at link/load time; thus,
class declarations and local variables have no linkage.
 All global objects implicitly have static storage class, so if you say (at file scope),
int a = 0;
then storage for a will be in the program’s static data area, and the initialization for
a will occur once, before main( ) is entered. In addition, the visibility of a is global
across all translation units. In terms of visibility, the opposite of static (visible only
in this translation unit) is extern, which explicitly states that the visibility of the
name is across all translation units. So the definition above is equivalent to saying
extern int a = 0;
But if you say instead,
static int a = 0;
All you’ve done is change the visibility, so ‘a’ has internal linkage. The storage
class is unchanged – the object resides in the static data area whether the visibility is
static or extern.

Global variables***
 Global variables are defined outside all function bodies and are available to all parts
of the program (even code in other files).
 Global variables are unaffected by scopes and are always available (i.e., the lifetime
of a global variable lasts until the program ends).
 If the existence of a global variable in one file is declared using the extern keyword
in another file, the data is available for use by the second file.

 Global variables are variables declared outside any block including main function.
 They are visible in all blocks in all files in the same process.
 In files, other than the one where the global variable is defined, you have to use
keyword extern to tell the compiler: "The following global variable whose name is
xxx and whose type is xxx is defined elsewhere, and you have to find out where
yourself."
 Global variables can be defined in either a header file or a source file.
 But if you define a global variable in a header file, then when more than one files
include that header file, multiple copies of the same global variable will be

28
instantiated, and you will have link errors. So you should normally put the
definition of global variables in a source file.
Examples:

Example1

Output will be:

123
123
But the above approach is not what people normally do. Because this approach
requires each file which uses those global variables to declare all of them which
keyword extern one by one, causing redundant code and is error-prone. The normal
approach is to create a separate header file and put all extern declarations of the

29
global variables in it. Logically this header file should have the same name as the
source file, but it can be different (as shown in the following example). Then all
files which accesses the global variables can simply include this header file:

Example2

Output will be:

30
 123
123

Constant global variables***

 In a sense, the reason you want to use global variable is to pass data between
several objects which do not have much coupling between them. Therefore global
variables should normally not be constant.
 When you use a constant global variable, you actually want a symbol or an alias for
a constant. Therefore it is clearer to use a #define to define this constant.
 For this reason, C++ compiler would not support syntax "extern const ...".
 If you want to have a constant global variable, you should put it in the header file
(Any.h). Compiler will treat it in the same way as a #define

Creation and deletion of Global Variables***

 The global object's constructors are called before any program is executed, and their
destructors are called after all program ends
 Because global objects are created before any code is executed, they must not be
any resource that cannot be initialized "on the spot" and has to be initialized by the
program.
 If you have to have a global resource like that, create a global reference (pointer) to
the resource, which can be initialized to NULL on the spot, then create and initialize
the resource in the program.

Global (static) initialization dependency*** (???)

 Within a specific translation unit, the order of initialization of static objects is
guaranteed to be the order in which the object definitions appear in that translation
unit. The order of destruction is guaranteed to be the reverse of the order of
initialization.
However, there is no guarantee concerning the order of initialization of static
objects across translation units, and the language provides no way to specify this
order. This can cause significant problems
Exmple

The program may work, and it may not. It completely depends on the order the files
are initialized in the programming environment.
 There are three approaches to dealing with this problem:
1. Don’t do it. Avoiding static initialization dependencies is the best solution.

31
2. If you must do it, put the critical static object definitions in a single file, so you
can portably control their initialization by putting them in the correct order.
3. If you’re convinced it’s unavoidable to scatter static objects across translation
units – as in the case of a library, where you can’t control the programmer who
uses it – there are two programmatic techniques (the third one was used by
comiler writers to to solve stream initialization/deinitialization issues) the
problem.
o Construct on First Use Idiom: - The basic idea of the Construct on First
Use Idiom is to wrap your static object inside a function.
For example, suppose you have two classes, Fred and Barney. There is a
namespace-scope / global Fred object called x, and a namespace-scope /
global Barney object called y. Barney’s constructor invokes the
goBowling() method on the x object. The file x.cpp defines the x object:
The Problem

You would have a static initialization disaster if y got constructed before x.

The Solution

The downside of this approach is that the Fred object is never destructed. If
the Fred object has a destructor, there is another technique (with important
side effects) that answers this concern; but it needs to be used with care
since it creates the possibility of another (equally nasty) problem
o Construct on First Use Idiom without Leak: - sometimes people worry about
the fact that the previous solution “leaks.” In many cases, this is not a
32
 problem, but it is a problem in some cases. Note: even though the object
pointed to by ans in the previous FAQ is never deleted, the memory doesn’t
actually “leak” when the program exits since the operating system
automatically reclaims all the memory in a program’s heap when that
program exits. In other words, the only time you’d need to worry about this
is when the destructor for the Fred object performs some important action
(such as writing something to a file) that must occur sometime while the
program is exiting.
In those cases where the construct-on-first-use object (the Fred, in this case)
needs to eventually get destructed, you might consider changing
function x()as follows:

However there is (or rather, may be) a rather subtle problem with this
change
By changing the declaration from static Fred* ans = new Fred(); to static
Fred ans;, we still correctly handle the initialization situation but we no
longer handle the deinitialization situation. For example, if there are 3 static
objects, say a, b and c, that use ans during their destructors, the only way to
avoid a static deinitialization disaster is if ans is destructed after all three.
The point is simple: if there are any other static objects whose destructors
might use ans after ans is destructed, bang, you’re dead. If
the constructors of a, band c use ans, you should normally be okay since the
runtime system will, during static deinitialization, destruct ans after the last
of those three objects is destructed. However if a and/or b and/or c fail to
use ans in their constructors and/or if any code anywhere gets the address
of ans and hands it to some other static object, all bets are off and you have
to be very, very careful.

o Nifty Counter Idiom: -

http://www.petebecker.com/js/js199905.html
https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Nifty_Counter

Static members and inheritance

Static members
 All objects share the same static storage space for the static data member, so it is a
way for them to “communicate” with each other
 Because static data has a single piece of storage regardless of how many objects are
created, that storage must be defined in a single place. The compiler will not
allocate storage for you. The linker will report an error if a static data member is
declared but not defined.

33
 The definition must occur outside the class (no inlining is allowed), and only
one definition is allowed. Thus, it is common to put it in the implementation
file for the class.
With static consts of integral types you can provide the definitions inside the class,
but for everything else (including arrays of integral types, even if they are static
const) you must provide a single external definition for the member. These
definitions have internal linkage, so they can be placed in header files.
You can also create static const objects of class types and arrays of such objects.
However, you cannot initialize them using the “inline syntax” allowed for
staticconsts of integral built-in types:
Example:
//StaticObjectArrays.cpp
// Static arrays of class objects
class X
{
int i;
public:
X(int ii) : i(ii) {}
};
class Stat
{
//static consts are initialized in-place:
static const int scSize = 100;
//Arrays, Non-integral and non-const statics must be initialized externally:
static const int scInts[];
static const long scLongs[];
static int size;
static float table[];

// This doesn't work, although you might want it to:

//! static const X x(100);
// Both const and non-const static class objects must be initialized externally:
static X x2;
static X xTable2[];
static const X x3;
static const X xTable3[];
};
int Stat::size = 100;
const int Stat::scInts[] = { 99, 47, 33, 11, 7 };
const long Stat::scLongs[] = {99, 47, 33, 11, 7 };
float Stat::table[4] = { 1.1, 2.2, 3.3, 4.4};

X Stat::x2(100);
X Stat::xTable2[] = { X(1), X(2), X(3), X(4) };
const X Stat::x3(100);
const X Stat::xTable3[] = { X(1), X(2), X(3), X(4) };
int main()
{

34
 Stat v;
}
 You cannot have static data members inside local classes (a local class is a class
defined inside a function). Thus
//Local class cannot have static data members:
void f()
{
class Local
{
public:
//! static int i; // Error
//(How would you define i?)
} x;
}

Statics and Inhiretance***

 Static members are inherited based on the access specifiers.
 There is only one copy of any static variable. If another class inherits it, it only
gets access to the same static variable, not another copy.
 You can't override HandleTimer in your subclass and expect this to work:

Base *e = new Derived();

e->BaseStaticMethode();

This is because static methods don't have an entry in the vtable, and can't thus
be virtual.

Extern***
 It tells the compiler that a variable or a function exists, even if the compiler hasn’t
yet seen it in the file currently being compiled.
 This variable or function may be defined in another file or further down in the
current file.
 Example
//Forward.cpp
// Forward function & data declarations
#include <iostream>
using namespace std;
// This is not actually external, but the compiler must be told it exists somewhere:
extern int i;
extern void func();
int main()
{
i = 0;
func();
}
int i; // The data definition

35
 void func()
{
i++;
cout << i;
}
 When the compiler encounters the declaration ‘extern int i’, it knows that the
definition for i must exist somewhere as a global variable. When the compiler
reaches the definition of i, no other declaration is visible, so it knows it has found
the same i declared earlier in the file.
 If you were to define i as static, you would be telling the compiler that i is defined
globally (via the extern), but it also has file scope (via the static), so the compiler
will generate an error.
 Alternate linkage specifications :
If you’re writing a program in C++ and you want to use a C library, the linkage may
not happen correctly.
If you make the C function declaration,
float f(int a, char b);
The C++ compiler will decorate this name to something like _f_int_char to support
function overloading (and type-safe linkage). However, the C compiler that
compiled your C library has most definitely not decorated the name, so its internal
name will be _f. Thus, the linker will not be able to resolve your C++ calls to f( ).
The escape mechanism provided in C++ is the alternate linkage specification, which
was produced in the language by overloading the extern keyword. The extern is
followed by a string that specifies the linkage you want for the declaration,
followed by the declaration:
extern "C" float f(int a, char b);
If you have a group of declarations with alternate linkage, put them inside braces,
like this:

extern "C" {
float f(int a, char b);
double d(int a, char b);
}

Or, for a header file,

extern "C" {
#include "Myheader.h"
}
Most C++ compiler vendors handle the alternate linkage specifications inside their
header files that work with both C and C++, so you don’t have to worry about it.

Linkage***
 In an executing program, an identifier is represented by storage in memory that
holds a variable or a compiled function body. Linkage describes this storage as it is
seen by the linker.
 There are two types of linkage: internal linkage and external linkage.

36
 Internal linkage
o Internal linkage means that storage is created to represent the identifier
only for the file being compiled. Other files may use the same identifier
name with internal linkage, or for a global variable, and no conflicts will be
found by the linker – separate storage is created for each identifier. Internal
linkage is specified by the keyword static in C and C++.
 External linkage
o External linkage means that a single piece of storage is created to represent
the identifier for all files being compiled. The storage is created once, and
the linker must resolve all other references to that storage. Global variables
and function names have external linkage. These are accessed from other
files by declaring them with the keyword extern.
o Variables defined outside all functions (with the exception of const in C++)
and function definitions default to external linkage. You can specifically
force them to have internal linkage using the static keyword.
o You can explicitly state that an identifier has external linkage by defining it
with the extern keyword. Defining a variable or function with extern is not
necessary in C, but it is sometimes necessary for const in C++.
Automatic (local) variables exist only temporarily, on the stack, while a function is
being called. The linker doesn’t know about automatic variables, and so these have no
linkage

Constants***
http://en.cppreference.com/w/cpp/language/cv
http://en.cppreference.com/w/cpp/language/constant_expression

 Any data type, built-in or user-defined, may be defined as const. If you define
something as const and then attempt to modify it, the compiler will generate an
error.
 In C++, a const must always have an initialization value otherwise there is a
compiler error.
 Constant values for built-in types are expressed as decimal, octal, hexadecimal, or
floating-point numbers (sadly,binary numbers were not considered important), or as
characters
Example: -
const int PerfectNumber; //Compiler Error; const has to be initialized
const int PerfectNumber = 10; //OK;
extern int PrefectNumber; //No Compiler Error; as it works as a
declaration //and compiler assumes the definition
in some //other translation unit.
//There may be a linker error if PrefectNumber is
not defined in other translation unit.
 You can place const definitions inside header files and distribute it to translation
units by including the header file.
 By default constant has internal linkage, that is, it is visible only within the file
where it is defined and cannot be seen at link time by other translation units. The
const can be made to have external linkage, if extended explicitly in the definition.

37
 Example
extern int PrefectNumber = 10;
 Storage allocation: Normally, the C++ compiler avoids creating storage for a
const, but instead holds the definition in its symbol table. In the ordinary case no
storage is allocated. When the const is used, it is simply folded in at compile time
 You force the storage allocation for const
o When you use extern with const : In this case storage must be allocated
because extern says “use external linkage,” which means that several
translation units must be able to refer to the item, which requires it to have
storage
o When you take the address of a const
o When you declare a complicated structure as a const: In this case you’re
virtually assured that the compiler will not be sophisticated enough to keep
an aggregate in its symbol table, so storage will be allocated Storage.
Whenever the compiler must allocate storage, constant folding is prevented (since
there’s no way for the compiler to know for sure what the value of that storage is –
if it could know that, it wouldn’t need to allocate the storage).

 Why internal linkage by default

Because the compiler cannot always avoid allocating storage for a const, const
definitions must default to internal linkage, that is, linkage only within that
particular translation unit. Otherwise, linker errors would occur with complicated
consts because they cause storage to be allocated in multiple cpp files. The linker
would then see the same definition in multiple object files, and complain. Because a
const defaults to internal linkage, the linker doesn’t try to link those definitions
across translation units, and there are no collisions. With built-in types, which are
used in the majority of cases involving constant expressions, the compiler can
always perform constant folding.

 Compiler might not do a constant folding2 but if folded and no extern specified
there will be no location

 It’s possible to use const for aggregates, but you’re virtually assured that the
compiler will not be sophisticated enough to keep an aggregate in its symbol table,
so storage will be allocated.
In these situations, const means “a piece of storage that cannot be changed.”
However, the value cannot be used at compile time because the compiler is not
required to know the contents of the storage at compile time. In the following
code, you can see the statements that are illegal:

//Constag.cpp
// Constants and aggregates
const int i[] = { 1, 2, 3, 4 };
//! float f[i[3]]; // Illegal
2
Constant folding refers to reducing constant expressions at compile time. Nearly all C++ compilers fold
arithmetic expressions such as ``2+2'' (to “4”) at compile time. Programmers generally do not write
expressions such as (3 + 5) directly, but these expressions are relatively common after macro expansion
and other optimizations such as constant propagation.

38
 struct S { int i, j; };
const S s[] = { { 1, 2 }, { 3, 4 } };
//! double d[s[1].j]; // Illegal
int main() {}

 Since a const in C++ defaults to internal linkage, you can’t just define a const in one
file and reference it as an extern in another file. To give a const external linkage so
it can be referenced from another file, you must explicitly define it as extern, like
this:
extern const int x = 1;
Notice that by giving it an initializer and saying it is extern, you force storage to be
created for the const (although the compiler still has the option of doing constant
folding here). The initialization establishes this as a definition, not a declaration.
The declaration:
extern const int x

 constexpr specifier (since C++11)

http://en.cppreference.com/w/cpp/language/constexpr

Mutable: bitwise vs. logical const

Bitwise const means that every bit in the object is permanent, so a bit image of the
object will never change. Logical const means that, although the entire object is
conceptually constant, there may be changes on a member-by member basis.
To effect logical constness, there are two ways to change a data member from within a
const member function.
The first approach is the historical one and is called casting away constness. It is
performed in a rather odd fashion. You take this (the keyword that produces the address
of the current object) and cast it to a pointer to an object of the current type. It would
seem that this is already such a pointer. However, inside a const member function it’s
actually a const pointer, so by casting it to an ordinary pointer, you remove the
constness for that operation. Here’s an example:
//Castaway.cpp
//"Casting away" constness
class Y
{
int i;
public:
Y();
void f() const;
};
Y::Y() { i = 0; }
void Y::f() const
{
//! i++; // Error -- const member function
((Y*)this)->i++; // OK: cast away const-ness
(const_cast<Y*>(this))->i++; // Better: use C++ explicit cast syntax:

39
}
int main()
{
const Y yy;
yy.f(); // Actually changes it!
}
The problem with this approach is that this lack of constness is hidden away in a
member function definition, and you have no clue from the class interface that the data
of the object is actually being modified unless you have access to the source code.
To second approach is to put everything out in the open by using the mutable keyword
in the class declaration to specify that a particular data member may be changed inside
a const object
//Mutable.cpp
//The "mutable" keyword
class Z
{
int i;
mutable int j;
public:
Z();
void f() const;
};
Z::Z() : i(0), j(0) {}
void Z::f() const
{
//! i++; // Error -- const member function
j++; // OK: mutable
}
int main()
{
const Z zz;
zz.f(); // Actually changes it!
}

Volatile
 The qualifier const tells the compiler “This never changes” (which allows the
compiler to perform extra optimizations), the qualifier volatile tells the compiler
“You never know when this will change,” and prevents the compiler from
performing any optimizations based on the stability of that variable.
 Use this keyword when you read some value outside the control of your code, such
as a register in a piece of communication hardware
 A volatile variable is always read whenever its value is required, even if it was just
read the line before

References
 Reference has to be initialized.
 Dereferenced automatically
 Associated with the same variable throughout its life.

40
 Reference is never null.
 Pointer to Reference can be created
Example: -
int a(10),b(20);
int& ref(a);
int* pRef = &ref;
 Reference to a Pointer is also possible and useful in situations in which you want to
pass a pointer to some function which will modify it.
So you can use Reference to pointer instead of pointer to pointer.
Example
void fun(int*& ref) //fun is changing ref so the change will be reflected in
main
 Array of pointers is possible but array of References is illegal in C++

deltype specifier***

http://en.cppreference.com/w/cpp/language/decltype

auto specifier***

http://en.cppreference.com/w/cpp/language/auto

alignas specifier (Since C++ 11)***

http://en.cppreference.com/w/cpp/language/alignas

typedef specifier***

http://en.cppreference.com/w/cpp/language/typedef

Typename*** (???)
 The keyword typename was introduced to specify that the identifier that follows is a
type
Example

template <class T>

Class MyClass {
typename T::SubType * ptr;
...
};

template<typename T>
struct first {
typedef T * pointer;
};

41
 template<typename T>
class second {
first<T>::pointer p; // syntax error
};

 Here, typename is used to clarify that SubType is a type of class T. Thus, ptr is a
pointer to the type T::SubType
 According to the qualification of SubType being a type, any type that is used in
place of T must provide an inner type SubType.
 Note that typename is always necessary to qualify an identifier of a template as
being a type, even if an interpretation that is not a type would make no sense. Thus,
the general rule in C++ is that any identifier of a template is considered to be a
value, except it is qualified by typename
 Apart from this, typename can also be used instead of class in a template
declaration: template <typename T> class MyClass
 Real Example in STL
???

Elaborated type specifier***

http://en.cppreference.com/w/cpp/language/elaborated_type_specifier

Static Assertion***

http://en.cppreference.com/w/cpp/language/static_assert

asm declaration***

http://en.cppreference.com/w/cpp/language/asm

42
Definition
 Definition is an instruction to the compiler to allocate space.
 When and where allocated depends on the storage class.
 Definitions are declarations that fully define the entity introduced by the
declaration. Every declaration is a definition, except for the following:
 A function declaration without a function body
 Any declaration with an extern storage class specifier or with a language
linkage specifier (such as extern "C") without an initializer

 Declaration of a non-inline static data member inside a class definition

 Namespace scope declaration of a static data member that was defined

within the class with the constexpr specifier

 Declaration of a class name (by forward declaration or by the use of the

elaborated type specifier in another declaration)

 An opaque declaration of an enumeration

 Declaration of a template parameter

 A parameter declaration in a function declaration that isn't a definition

 A typedef declaration
 An alias-declaration

 A using-declaration
 Declaration of a deduction guide (does not define any entities). See Class
template deduction***
 A static_assert declaration (does not define any entities)
 An attribute declaration (does not define any entities)
 An empty declaration (does not define any entities)
 A using-directive (does not define any entities)

43
  An explicit instantiation declaration (an "extern template")

 An explicit specialization whose declaration is not a definition.

 An asm declaration does not define any entities, but it is classified as a

definition.

 C++ follows ODR (One definition Rule) When the linker is uniting all the object
modules, it will usually complain if it finds more than one definition for the same
function or variable.

44
Initialization***
http://en.cppreference.com/w/cpp/language/initialization

 Give a value at definition

 Only once
 Generally more efficient.
 Not an expression. (For ex: int a = b = 10; NO)
 Default Initialization value depends on storage class of the variable
 Static, global >= 0
 Otherwise: undefined in the language.

Default initialization***

http://en.cppreference.com/w/cpp/language/default_initialization

Value initialization***

http://en.cppreference.com/w/cpp/language/value_initialization

Copy initialization***

http://en.cppreference.com/w/cpp/language/copy_initialization

Direct initialization***

http://en.cppreference.com/w/cpp/language/direct_initialization

Aggregrate initialization***

http://en.cppreference.com/w/cpp/language/aggregate_initialization

List initialization (since C++11) ***

http://en.cppreference.com/w/cpp/language/list_initialization

Reference initialization***

http://en.cppreference.com/w/cpp/language/reference_initialization

45
Static non local initialization***

http://en.cppreference.com/w/cpp/language/initialization#Non-local_variables

Zero initialization***

http://en.cppreference.com/w/cpp/language/initialization#Non-local_variables

Constant initialization***

http://en.cppreference.com/w/cpp/language/constant_initialization

Dynamic non local initialization***

http://en.cppreference.com/w/cpp/language/initialization#Non-local_variables

46
Expressions
Value Categories
 Each C++ expression is characterized by two independent properties: a type and a
value category. Each expression has some non-reference type, and each expression
belongs to exactly one of the three primary value categories: prvalue, xvalue,
lvalue, defined as follows:
o a glvalue is an expression whose evaluation determines the identity of an
object, bit-field, or function
o a prvalue is an expression whose evaluation either
 computes the value of the operand of an operator (such prvalue has
no result object), or
 Initializes an object or a bit-field (such prvalue is said to have a
result object). All class and array prvalues have a result object even
if it is discarded.
o an xvalue is a glvalue that denotes an object or bit-field whose resources can
be reused
o An lvalue is a glvalue that is not an xvalue.
o An rvalue is a prvalue or an xvalue.
Note: this taxonomy went through significant changes with past C++ standard
revisions, see History below for details.
Primary categories
lvalue: -The following expressions are lvalue expressions:
 the name of a variable or a function in scope, regardless of type, such
as std::cin or std::endl. Even if the variable's type is rvalue reference, the
expression consisting of its name is an lvalue expression;
 a function call or an overloaded operator expression of lvalue reference return
type, such as std::getline(std::cin, str), std::cout << 1, str1 = str2, or ++it;
 a = b, a += b, a %= b, and all other built-in assignment and compound
assignment expressions;
 ++a and --a, the built-in pre-increment and pre-decrement expressions;
 *p, the built-in indirection expression;
 a[n] and p[n], the built-in subscript expressions, except where a is an array
rvalue (since C++11);
 a.m, the member of object expression, except where m is a member enumerator
or a non-static member function, or where a is an rvalue and m is a non-static data
member of non-reference type;
 p->m, the built-in member of pointer expression, except where m is a member
enumerator or a non-static member function;
 a.*mp, the pointer to member of object expression, where a is an lvalue
and mp is a pointer to data member;
 p->*mp, the built-in pointer to member of pointer expression, where mp is a
pointer to data member;
 a, b, the built-in comma expression, where b is an lvalue;
 a ? b : c, the ternary conditional expression for some a, b, and c;
 a string literal, such as "Hello, world!";
 a cast expression to lvalue reference type, such as static_cast<int&>(x);

47
 a function call or an overloaded operator expression of rvalue
reference to function return type;
(since C++11)
 a cast expression to rvalue reference to function type, such
as static_cast<void (&&)(int)>(x).
Properties:
 Same as glvalue (below).
 Address of an lvalue may be taken: &++i [1] and &std::endl are valid
expressions.
 A modifiable lvalue may be used as the left-hand operand of the built-in
assignment and compound assignment operators.
 An lvalue may be used to initialize an lvalue reference; this associates a new
name with the object identified by the expression.

Expression parser
Deciding operator does not depend on precedence or association; it works as follows:
 Compiler is greedy :- first phase is lexical analyzer which is greedy and finds the
longest possible token
For Example: -
int a = 10, b = 5;
a --- b;
//a - (--b) No
// a -- (-b) OK because of compiler’s greediness.

 The greediness of compiler creates problems in two places

 Default char* parameter
 Nested templates

Operators

Logical operators***
http://en.cppreference.com/w/cpp/language/operator_logical

Bitwise operators***
 The bitwise operators
Operator Name Description
a&b and 1 if both bits are 1. 3 & 5 is 1.
a|b or 1 if either bit is 1. 3 | 5 is 7.
a^b xor 1 if both bits are different. 3 ^ 5 is 6.

48
 This unary operator inverts the bits. If ints are stored as 32-bit
~a not
integers, ~3 is 11111111111111111111111111111100.
left Shifts the bits of n left p positions. Zero bits are shifted into the
n<<p
shift low-order positions. 3 << 2 is 12.
Shifts the bits of n right p positions. If n is a 2's complement
right
n>>p signed number, the sign bit is shifted into the high-order positions.
shift
5 >> 2 is 1.

Shift operators
 Usage
I << n (left shift I by n bits)
I >> n (Right shift I by n bits)
 The left-shift operator (<<) produces the operand to the left of the operator shifted
to the left by the number of bits (n) specified after the operator.
 The right-shift operator (>>) produces the operand to the left of the operator
shifted to the right by the number of bits (n) specified after the operator.
 If the value (n) after the shift operator is greater than the number of bits in the left-
hand operand, the result is undefined.
 If the left-hand operand is unsigned, the right shift is a logical shift so the upper bits
will be filled with zeros. If the left-hand operand is signed, the right shift may or
may not be a logical shift (that is, the behavior is undefined).
 Shifts can be combined with the equal sign (<<= and >>=). The lvalue is replaced
by the lvalue shifted by the rvalue.
 The << and >> provide bit-shifting behavior, but when they shift bits off the end of
the number, those bits are lost. When manipulating bits you can also perform
rotation, which means that the bits that fall off one end are inserted back at the other
end, as if they’re being rotated around a loop.
 Rotation Examples:
//Rotation.cpp
// Perform left and right rotations
unsigned char rol(unsigned char val)
{
int highbit;
if(val & 0x80) // 0x80 is the high bit only
highbit = 1;
else
highbit = 0;
//Left shift (bottom bit becomes 0):
val <<= 1;
//Rotate the high bit onto the bottom:
val |= highbit;
return val;
}
unsigned char ror(unsigned char val)
{
49
 int lowbit;
if(val & 1) //Check the low bit
lowbit = 1;
else
lowbit = 0;
val >>= 1; //Right shift by one position
//Rotate the low bit onto the top:
val |= (lowbit << 7);
return val;
}

 Convert a number to Binary

//printBinary.cpp
#include <iostream>
void printBinary(const unsigned char val)
{
for(int i = 7; i >= 0; i--)
if(val & (1 << i))
std::cout << "1";
else
std::cout << "0";
}
The above function takes a single byte and displays it bit by bit. The expression (1
<< i) produces a one in each successive bit position; in binary: 00000001,
00000010, etc. If this bit is bitwise anded with val and the result is nonzero, it
means there was a one in that position in val.

Packing and unpacking

A common use of the bitwise operators (shifts with ands to extract values and ors to
add values) is to pack multiple values in one int. [Bit-fields are another way to do this.]
For example, let's say you have the following integer variables: age (range 0-127
requires 7 bits), gender (range 0-1 requires 1 bit), and height (range 0-127 requires 7
bits). These can be packed and unpacked into/from one int by using only the minimum
number of bits to represent each variable. The 15 bits that these require could be stored
like this (A for age, G for gender, and H for height).

 Shift left multiplies by 2

50
 Shift right divides by 2

Check/Set/Clear/Flip the bit

 Check whether a specified bit is set or not: - To check the state of a bit (e.g.
pos_num) in a number (e.g. in_use) basically we need a number for which the
pos_num bit is 1 and all other bits are 0. This can be achieved
 by 2pos_num OR
 by shifting 1 pos_num bits to the left.

OR

Note that shifting by zero places is a legal operation -- we'll just get back the same
number we started with

 To clear a specified bit: - To clear the state of a bit (e.g. pos_num) we need a
number for which the pos_num is 0 and all other bits are 1. This can be achieved by
shifting 1 pos_num bits to the left and then complement the result.

 To flip a specified bit: - To check the state of a bit (e.g. pos_num) in a number (e.g.
in_use) basically we need a number for which the pos_num bit is 1 and all other bits
are 0.
When we perform the XOR with this number the state of the specified bit is
flipped.

Write a generic method to convert any unsigned number (int or long) to binary
number ???

The Conditional operator (ternary operator (?))***

 It’s a conditional operator and works similar to the if-else. The usage choice should
be based on the maintainability of the code.
51
 There is one difference when you can initialize a constant variable depending on
some expression:
const int x = (a<b) ? b : a;

You can't do the same with if-else.

Example

a = --b ? b : (b = -99);

Here a is assigned to the value of b if the result of decrementing b is nonzero. If b

became zero, a and b are both assigned to -99. b is always decremented, but it is
assigned to -99 only if the decrement causes b to become 0. Similar statement can
be used without the “a =” just for its side effects:

--b ? b : (b = -99);

Here the second b is superfluous, since the value produced by the operator is
unused. An expression is required between the ? and :. In this case, the expression
could simply be a constant that might make the code run a bit faster i.e. it can be
rewritten as

const int X;

--b ? X : (b = -99);

The Comma Operator***

 The comma operator can also be used as an operator to separate expressions – in
this case it produces only the value of the last expression. All the rest of the
expressions in the comma-separated list are evaluated only for their side effects.
Example
//CommaOperator.cpp
#include <iostream>
using namespace std;
int main()
{
int a = 0, b = 1, c = 2, d = 3, e = 4;
a = (b++, c++, d++, e++);
cout << "a = " << a << endl;
//The parentheses are critical here. Without them, the statement will evaluate to:
//(a = b++), c++, d++, e++;
cout << "a = " << a << endl;
}
With parentheses a will be assigned 4 and without parentheses, it will be
assigned 1.
 The comma operator has the lowest precedence of all C/C++ operators. Therefore
it's always the last one to bind to an expression, meaning this:

52
 a = b, c;
is equivalent to:
(a = b), c;

 Another interesting fact is that the comma operator introduces a sequence point.
This means that the expression:
a+b, c(), d
is guaranteed to have its three subexpressions (a+b, c() and d) evaluated in order.
This is significant if they have side-effects. Normally compilers are allowed to
evaluate subexpressions in whatever order they find fit; for example, in a function
call:
someFunc(arg1, arg2, arg3)
Take care to notice that the comma operator may be overloaded in C++. The actual
behavior may thus be very different from the one expected.

The Compile-Time Operator sizeof

 The sizeof is a keyword, but it is a compile-time operator that determines the size,
in bytes, of a variable or data type.
 The sizeof operator can be used to get the size of classes, structures, unions and any
other user defined data type.
 The syntax of using sizeof is as follows:

sizeof (data type)

But if you apply it to a variable you can use it without parentheses

Common operators

Operator Precedence Summary

Precedence Operator Description Associativity

53
1 :: Scope resolution Left-to-right

++ -- Suffix/postfix increment and decrement

type() type{} Function-style type cast

() Function call
2

[] Array subscripting

. Element selection by reference

-> Element selection through pointer

++ -- Prefix increment and decrement Right-to-left

+ - Unary plus and minus

! ~ Logical NOT and bitwise NOT

(type) C-style type cast

3 * Indirection (dereference)

& Address-of

sizeof Size-of[note 1]

new, new[] Dynamic memory allocation

delete, delete[] Dynamic memory deallocation

54
4 .* ->* Pointer to member Left-to-right

5 * / % Multiplication, division, and remainder

6 + - Addition and subtraction

7 << >> Bitwise left shift and right shift

< <= For relational operators < and ≤ respectively

> >= For relational operators > and ≥ respectively

9 == != For relational = and ≠ respectively

10 & Bitwise AND

11 ^ Bitwise XOR (exclusive or)

12 | Bitwise OR (inclusive or)

13 && Logical AND

14 || Logical OR

15 ?: Ternary conditional[note 2] Right-to-left

= Direct assignment (provided by default for C+

+ classes)

+= -= Assignment by sum and difference

55
 Assignment by product, quotient, and
*= /= %=
remainder

<<= >>= Assignment by bitwise left shift and right shift

&= ^= |= Assignment by bitwise AND, XOR, and OR

16 throw Throw operator (for exceptions)

17 , Comma Left-to-right

Conversions

Casting operators

C-style cast
 C style cast are casts using (type)object or type(object).
 Generally the C-style cast will employ whatever combination of the below listed
casts is necessary to achieve the specified type conversion i.e. it is defined as the
first of the following which succeeds:
 const_cast
 static_cast
 static_cast then const_cast
 reinterpret_cast
 reinterpret_cast then const_cast
 It can therefore be used as a replacement for other casts in some instances, but can
be extremely dangerous because of the ability to devolve into a reinterpret_cast, and
the latter should be preferred when explicit casting is needed, unless you are sure
static_cast will succeed or reinterpret_cast will fail.
 C-style casts also ignore access control when performing a static_cast, which means
that they have the ability to perform an operation that no other cast can. This is
mostly a kludge and is just another reason to avoid C-style casts.

C++ explicit casts

 The new casts are less powerful and more specific than old-style cast.
 Each of the new cast has separate purposes, thus give the program more precise
control.

56
 Old style casting is still legal, but new casts are preferable

static_cast For “well-behaved” and “reasonably well-behaved” casts,

including things you might now do without a cast (such as an
automatic type conversion).
const_cast To cast away const and/or volatile
reinterpret_cast To cast to a completely different meaning. The key is that you’ll
need to cast back to the original type to use it safely. The type you
cast to, is typically used only for bit twiddling or some other
mysterious purpose. This is the most dangerous of all the casts.
dynamic_cast For type-safe downcasting

static_cast
 It is mainly used to cast up or down the inheritance hierarchy.
 It is used for cases where you basically want to reverse an implicit conversion, with
a few restrictions and additions.
 It only performs type checking at compile time. So it is safer than casting with "( )".
 It performs no runtime checks so it is the programmer's responsibility to make
sure that pBase is pointing to a Derived object. If not, there will be a run time
error. Thus this should be used if you know that you refer to an object of a specific
type, and thus a check would be unnecessary
 It doesn't do any run time checking of the types involved, which means that unless
you know what you are doing, they could be very unsafe.
 It also only allows casting between related types, such as pointers or references
between Base and Derived, or between fundamental types, such as long to int or int
to float.
 It does not allow casts between fundamentally different types, such as a cast
between a BaseA and BaseB if they are not related. This will result in a compile
time error.
 It can also cast through inheritance hierarchies. It is unnecessary when casting
upwards (towards a base class), but when casting downwards it can be used as long
as it doesn't cast through virtual inheritance
 Example:

57
dynamic_cast
 The dynamic_cast can only be used with pointers and references to objects.
 It makes sure that the result of the type conversion is valid and complete object of
the request class.
 dynamic_cast does run time checking as well, and if the instance cannot be cast into
another derived type, it will return a null pointer.
 This cast is used for cases where you don't know what the dynamic type of the
object is.
 You cannot use dynamic_cast if you downcast and the argument type is not
polymorphic.
 With dynamic_cast it is also possible to cast null pointers even between the pointers
of unrelated classes. Dynamic_cast can cast pointers of any type to void pointer
(void*)
 dynamic_cast returns a null pointer if the cast is not successful. (When you cast to a
reference, a bad_cast exception is thrown in that case).
 The following code is not valid, because Base is not polymorphic (doesn't contain a
virtual function):

 dynamic_cast has some limitations:-

i. It doesn't work if there are multiple objects of the same type in the
inheritance hierarchy (the so-called 'dreaded diamond') and you aren't using
virtual inheritance.

58
 ii. It also can only go through public inheritance - it will always fail to travel
through protected or private inheritance. This is rarely an issue; however, as
such forms of inheritance are rare.
Example:

 An "up-cast" is always valid with both static_cast and dynamic_cast, and also
without any cast, as an "up-cast" is an implicit conversion

const_cast
 const_cast casts away const or volatile. It can be used to remove or add const to a
variable; no other C++ cast is capable of removing it (not even reinterpret_cast)
 It only works on pointers, not objects.
 You can use it to modify a data member in a const method:
 It is important to note that using it is only undefined if the original variable is
const; if you use it to take the const of a reference to something that wasn't
declared with const, it is safe.
 This can be useful when overloading member functions based on const, for
instance. It can also be used to add const to an object, such as to call a member
function overload.
 const_cast also works similarly on volatile, though that's less common

reinterpret_cast
 reinterpret_cast is the most dangerous cast, and should be used very sparingly.
 It turns one type directly into another - such as casting the value from one pointer to
another, or storing a pointer in an int, or all sorts of other nasty things
 Largely, the only guarantee you get with reinterpret_cast is that if you cast the result
back to the original type, you will get the same value
 reinterpret_cast is used for cases that yield implementation-dependent results,
such as casting between function pointer types.

59
 Because it allows you to do nonstandard strange conversions, dangerous
manipulations can be done, and the result may be machine-dependent.

Run Time Type Identification (RTTI)

Why RTTI
 Because of polymorphism, when you write your program, you may not be able to
know the exact type you are dealing with. But there are cases in which you do need
to find out the exact type of the polymorphic object and deal with it differently
according to its type.
 Run-time type information (RTTI) is used to find out the type of a polymorphic
object.

What RTTI supports

 Runtime Type Information (RTTI) is the concept of determining the type of any
variable during runtime. The RTTI mechanism contains:
 The operator dynamic_cast
 The operator typeid
 The struct type_info
 RTTI can only be used with polymorphic types. This means that with each class you
make, you must have at least one virtual function (either directly or through
inheritance).

What to use, dynamic_cast or typeid()

 If a class hierarchy is used then the programmer doesn’t have to worry (in most
cases) about the data-type of a pointer or reference, because the polymorphic
mechanism takes care of it.
 In some cases the programmer wants to know if an object of a derived class is used.
Then the programmer can make use of dynamic_cast (If the dynamic cast is
successful, then the pointer will point to an object of a derived class or to a class
that is derived from that derived class.)
 But there are circumstances that the programmer (not often) wants to know the data
type. Then the programmer can use the typeid() operator.

typeid()
 The C++ standard provides the typeid() operator for getting type information.
The typeid() operator can be used with :
 Variables
 Expressions
 Data-types
 The typeid returns a const reference of class type_info, which is a class description
of the operand
 Class type_info has a method name(), which returns a char * which is the type
name of the operand
 Example

60
 If class Base and Derived are polymorphic types i.e. they have virtual
functions, the output will be:
typeid(pBase1) = class Base1 *
typeid(*pBase1) = class Derived
If class Base and Derived do not have virtual functions, the output will be:
typeid(pBase1) = class Base1 *
typeid(*pBase1) = class Base
 A bad_typeid exception is thrown by typeid(), if the type that is evaluated by
typeid is a null pointer and is preceded by a dereference operator.

type_info
 The type_info class has only a few members functions:
 const char* name() for getting the string representation of the type. For
example ‘int’ or ‘MyClass’ etc.
 bool before(const type_info&) for ordering
 operator==() and operator! =() for comparing type_info objects.

standard conversions***
http://en.cppreference.com/w/cpp/language/implicit_conversion

const_cast conversion
http://en.cppreference.com/w/cpp/language/const_cast

static_cast conversion
http://en.cppreference.com/w/cpp/language/static_cast

61
dynamic_cast conversion
http://en.cppreference.com/w/cpp/language/dynamic_cast

reinterpret_cast conversion
http://en.cppreference.com/w/cpp/language/reinterpret_cast

explicit cast conversion

http://en.cppreference.com/w/cpp/language/explicit_cast

 Using C-style cast notation and functional notation

User-defined conversion
http://en.cppreference.com/w/cpp/language/cast_operator

 Makes it possible to specify conversion from user-defined classes

Null-Terminated Strings***
 C++ provides following two types of string representations:
 The C-style character string
 The string class type
 The C-style character (null-terminated) string is actually a one-dimensional array of
characters which is terminated by a null character '\0'.
 Initialization of null-terminated character sequences
 The C++ compiler automatically places the '\0' at the end of the string when
it initializes the array

\\like any other array, null character added explicitly

char myword[] = { 'H', 'e', 'l', 'l', 'o', '\0' };

\\As a string literal; Compiler adds the null character

char myword[] = "Hello";

 Because string literals are regular arrays, they have the same restrictions as
these, and cannot be assigned values.

 Once myword has already been declared, the below expressions would not
be valid:
myword = "Bye"; \\Invalid; Assignment not possible
myword[] = "Bye"; \\Invalid; Assignment not possible
myword = { 'B', 'y', 'e', '\0' }; \\Invalid; Assignment not possible

The above expressions are invalid because arrays cannot be assigned values.
Note, though, that each of its elements can be assigned a value individually.

62
 For example, this would be correct:
myword[0] = 'B';
myword[1] = 'y';
myword[2] = 'e';
myword[3] = '\0';

 C++ supports a wide range of functions that manipulate null-terminated

strings:

63
 Classes
Encapsulation
 Put together attributes and behavior.
 Hide implementation.
 Expose interface.
 Server code modified should not cascade into changes in the client code.
Abstraction
 Selecting essential features.
 Ignore what is not essential.

Class types

-----------------------------------------------
 No member can be declared as auto, extern, or register
 Methods provided by compiler by default
i. default constructor
ii. destructor
iii. copy constructor
iv. assignment operator
v.
 Like C++ class both struct and union can also have a constructor, destructor, member
functions, and even access control. The only difference between struct and class in C++
is that struct defaults to public and class defaults to private.
 However, a union cannot be used as a base class during inheritance, which is quite
limiting from an object-oriented design standpoint. The reason for using a union as a
class is to save space. Instead of replacing class with union, the correct design to
achieve this is by encapsulating union in a class.
Example
//SuperVar.cpp
//A super-variable
#include <iostream>
using namespace std;
class SuperVar
{
enum
{
character,
integer,
floating_point
} vartype; // Define one
union
{ // Anonymous union
char c;
int i;
float f;

64
 };
public:
SuperVar(char ch);
SuperVar(int ii);
SuperVar(float ff);
void print();
};
SuperVar::SuperVar(char ch)
{
vartype = character;
c = ch;
}
SuperVar::SuperVar(int ii)
{
vartype = integer;
i = ii;
}
SuperVar::SuperVar(float ff)
{
vartype = floating_point;
f = ff;
}
void SuperVar::print()
{
switch (vartype)
{
case character:
cout << "character: " << c << endl;
break;
case integer:
cout << "integer: " << i << endl;
break;
case floating_point:
cout << "float: " << f << endl;
break;
}
}
int main()
{
SuperVar A('c'), B(12), C(1.44F);
A.print();
B.print();
C.print();
}

C++ header files***

 C++ header files should contain

65
 o Variable declaration
o Function declaration
o Constant definition (should not be extern)
o type definitions
o inline fn definition
o Template function definition (why?)

Union types
 If a union has no type name and no variable name, it’s called an anonymous union,
and creates space for the union but doesn’t require accessing the union elements
with a variable name and the dot operator. For instance, if your anonymous union
is:
//AnonymousUnion.cpp
int main()
{
union
{
int i;
float f;
};
//Access members without using qualifiers:
i = 12;
f = 1.22;
}
Note that you access members of an anonymous union just as if they were ordinary
variables. The only difference is that both variables occupy the same space.
 If the anonymous union is at file scope (outside all functions and classes) then it
must be declared static so it has internal linkage.

Constructors

 Default constructor
Default constructor is called implicitly when you create an array of objects. If you want
to have an array of objects that do not have a default constructor, the work-around is to
have an array of pointers and initialize them using operator new.
 One argument constructors
 One-argument constructors are called user-defined converters.
 Suppose a method has an argument of type "Child", which has an one-argument
constructor "Child (Parent)". When you call this method, if you pass a "Parent"
object instead of "Child", the compiler will implicitly call the one-argument
constructor and convert the "Parent" object to "Child".
Example

66
Explicit constructor***
 By using the keyword explicit, you can prohibit a single argument constructor from
defining an automatic type conversion.
 A typical example of the need for this feature is in a collection class in which you
can pass the initial size as constructor argument. For example, you could declare a
constructor that has an argument for the initial size of a stack:

Here, the use of explicit is rather important. Without explicit this constructor would
define an automatic type conversion from int to Stack. If this happens, you could
assign an int to a Stack:

The automatic type conversion would convert the 40 to a stack with 40 elements
and then assign it to s. This is probably not what was intended. By declaring the int
constructor as explicit, such an assignment results in an error at compile time.

67
 Note that explicit also rules out the initialization with type conversion by using
the assignment

This is because there is a minor difference between

The former creates a new object of type Y by using an explicit conversion from
type X, whereas the latter creates a new object of type Y by using an implicit
conversion.

Constructor gotcha***
Consider that we have a class Ex
Ex ex; //OK; default constructor will be called

Ex ex(); //No; Compiler treats it as a function declaration which returns Ex type

object

ex.Ex(); //Its actually ObjectName.ctor()

//NO;
//Constructor has to be associated with an object that is being initialized

Ex(); //OK; Possible;

//Compiler provides a temporary object which will be initialized

Storage allocation for classes

 A variable can be defined at any point in a scope, so it might seem that the storage
for a variable may not be defined until its point of definition. It’s actually more
likely that the compiler will follow the practice in C of allocating all the storage for
a scope at the opening brace of that scope.
 Although the storage is allocated at the beginning of the block, the constructor call
doesn’t happen until the sequence point where the object is defined because the
identifier isn’t available until then. The compiler even checks to make sure that you
don’t put the object definition (and thus the constructor call, either on heap or stack)
where the sequence point only conditionally passes through it, such as in a switch
statement or somewhere a goto can jump past it
 Example:
/Nojump.cpp
//Can't jump past constructors

68
 class X
{
public:
X();
};
X::X() {}
void f(int i)
{
switch(i)
{
case 1 :
X x2; // Error: case bypasses init (X * x2 = new X; also fails)
break;
case 2 : // Error: case bypasses init
X x3;
break;
}
}
int main()
{
f(9);
f(11);
}

Initialization lists***
http://en.cppreference.com/w/cpp/language/initializer_list#Initialization_order

 Allowed only in constructors and copy constructors

 Initialization list required for the initialization of: -
 constant members
 reference members
 base class sub objects
 If the member name is same as the name of the argument to your constructor
 Preferred even for variables
 Order of initialization: -
 order of declaration in the class
 Top to bottom and left to right
 Initialization Lists and Exceptions: - Since constructors can throw exceptions, it's
possible that you might want to be able to handle exceptions that are thrown by
constructors invoked as part of the initialization list.
The syntax for catching an exception in an initialization list is somewhat
awkward: the 'try' goes right before the colon, and the catch goes after the
body of the function:
Example
class Foo
{
Foo() try : _str( "text of string" )

69
 {
}
catch ( ... )
{
std::cerr << "Couldn't create _str";
//now, the exception is rethrown as if we'd //written
// "throw;" here
}
private:
string _str;
};

Destructors

 No return type and no parameters

 Called when object dies
 Cannot be overloaded, Only one for a class

Copy Constructor???

 The…
 According to the C++ standard, the copy constructor for MyClass must have
one of the following signatures:

Note that none of the following constructors, despite the fact that they could do the
same thing as a copy constructor, are copy constructors:

Assignment operator (Copy Assignment operator) ***

 A copy assignment operator of class T is a non-template non-static member

function with the name operator= that takes exactly one parameter of
type T, T&, const T&, volatile T&, or const volatile T&.
 Syntax

70
 If no user-defined copy assignment operators are provided for a class type, the
compiler will always declare one as an inline public member of the class.
 This implicitly-declared copy assignment operator has this form, if all of the
following is true.

T& T::operator=(const T&)

o Each direct base B of T has a copy assignment operator whose parameters

are B or const B& or const volatile B&;
o Each non-static data member M of T of class type or array of class type has
a copy assignment operator whose parameters
are M or const M& or const volatile M&.

 Otherwise the implicitly-declared copy assignment operator is declared as

T& T::operator=(T&).
 An assignment operator performs below actions :-

 Due to the risk of failure in the memory allocation process for the target object it’s
risky to do the de-allocation so copy-and-swap idiom should be used
 A class can have multiple copy assignment operators, e.g.
both T& T::operator=(const T&) and T& T::operator=(T). If some user-defined
copy assignment operators are present, the user may still force the generation of the
implicitly declared copy assignment operator with the keyword default. (since C+
+11)
 The implicitly-defined copy assignment operator for a non-union class X performs
memberwise copy assignment of its subobjects. The direct base classes of X are
assigned first, in the order of their declaration in the base-specifier-list, and then the
immediate non-static data members of X are assigned, in the order in which they
were declared in the class definition. Each subobject is assigned in the manner
appropriate to its type:
o If the subobject is of class type, the copy assignment operator for the class is
used (as if by explicit qualification; that is, ignoring any possible virtual
overriding functions in more derived classes);

71
 o If the subobject is an array, each element is assigned, in the manner
appropriate to the element type;
o If the subobject is of scalar type, the built-in assignment operator is used.
 Because the copy assignment operator is always declared for any class, the base
class assignment operator is always hidden. If a using-declaration is used to bring in
the assignment operator from the base class, and its argument type could be the
same as the argument type of the implicit assignment operator of the derived class,
the using-declaration is also hidden by the implicit declaration.
 A C++ 'reference' can only be initialized, not assigned. Therefore, an
object containing a reference can only be initialized, too. So indeed: if you need
assignment on a class, that class cannot have reference member variables.
 A static member is shared by all the objects of a class. Therefore, static member’s
assignment must be avoided while implementing the assignment operator for the
class.
 If you mark a member variable as const, this expresses that this variable will not
(should not!) change its value during the lifetime of the object. So clearly, assigning
a new value to the object violates this statement. So if you indeed don't want the
member to change, just don't make it const.
An example of assignment operator with const member

 Example : Consider the following class definition

The big mistake

72
 Transactionization failure

The problem here is that if you’re trying to transactionize the assignment, so that
either all of it happens or none of it happens, this breaks that. If an exception occurs
trying to new up bar1 or bar2, the TFoo part of the object won’t have changed, but
the TSuperFoo part will have. The call to TSuperFoo::operator=() can’t go at the
top of the function.

73
Unfortunately, that’s wrong too. The problem is we’re still hosed if TSuperFoo’s
assignment operator can also throw an exception, which is a reasonable thing to
expect. If we succeed in creating our TBarobjects, but TSuperFoo::operator=() fails
to create whatever he needs to (presumably he’s also transactionized), the object
will correctly be left untouched, but we’ll leak the new TBars we created. So
theright answer (he said sheepishly) is this:

74
The call to TSuperFoo::operator=() has to go inside the try. Notice that it
goes after we create the new TBars. We want to make sure creating the TBars has
succeeded before we
call TSuperFoo::operator=()because TSuperFoo::operator=() might succeed,
changing the object, and we only want to change the object if we can carry out the
whole assignment operation.

One interesting consequence of this is that you can imagine a class with a fairly
deep inheritance chain where every class up the chain has other objects it owns.
You’d call an assignment operator low in the chain, it’d create the objects it needs,
then it’d call its parent, which would create the objects it needs and call its parent,
and so on up the chain. Eventually, all of the new objects would have been created
and would be pointed to by temporary variables on the stack. Then, at the root level,
the assignment would finally begin to be carried out, with objects being deleted and
the object’s data members being changed as each function returned. So the
allocations happen in one order and the assignments and deletions happen in reverse
order, which feels kind of awkward at first glance, but it gets the job done. It also
means that there has to be enough free memory to hold two instances of every
subobject, but there really isn’t a safe way around allocating all the extra memory.

The solution

75
 Copy assignment operator can be expressed in terms of copy constructor, destructor,
and the swap() member function, if one is provided

Virtual assignment operator***

 Unlike the other operator functions, the assignment operator function cannot be
inherited by derived classes. If, for any class X, there is no user-defined operator =,
the operator = is defined by default as a member-by-member assignment of the
members of class X
 A base class assignment operator is always hidden by the copy assignment
operator of the derived class.
 If you overload the assignment operator in base class but derived class operator is
not overloaded as per the standard a default assignment operator in derived is
generated which calls the overloaded assignment operator of the Base class to
complete the assignment process
Example:

 Any assignment operator, even the copy assignment operator, can be virtual. [Note:
for a derived class D with a base class B for which a virtual copy assignment has

76
 been declared, the copy assignment operator in D does not override B’s virtual copy
assignment operator.
Example:

 Partial assignment problem***

Partial assignment happens when a derived class object is assigned to a base-class
pointer or reference. In this case only the base-class part of the data is assigned.
Consider an example:-

77
setX will work perfectly fine if X is a monomorphic class but for our example
where X is polymorphic setX will not work correctly
If either x or newX points to an object of class Y or Z, we’ll slice. Only the
members defined in X will get copied.
If x is an instance of Y or Z, the members defined by Y or Z won’t get led in with
new values.
If newX is an instance of Y or Z, the members defined by Y or Z won’t get copied
into x.

The problem here, of course, is that we’re calling X’s assignment operator even
when x isn’t an instance of X. The obvious solution, therefore, would be to
make X’s assignment operator virtual. Then the correct assignment operator would
be called. If we do this, the assignment operators would look like this:

Now, if x and newX are actually both instances of Y, Y’s assignment operator will
get called and everybody will work right

Well, consider the situation where x is a Y and newX is a Z. In this case,

the dynamic_cast will fail, throwing a bad_cast exception
Remember that after an assignment succeeds, the objects on either side of the = are
to be computationally equivalent. That is, all of their visible state and their behavior
should be the same. This implies that they should be the same class. What you
really want is for it to look like x morphed from whatever class it was to the same
class newX is. X, Y, and Z’s assignment operators can’t do this; there’s no way to
morph an existing object from one class to another (well, there kind of is, but we’ll
get to it later). Instead, setX() has to deal with this:

78
 clone()3 is the polymorphic copy constructor.

Another alternative is that setX() doesn’t handle this condition, but some other class
up the inheritance chain will have to, probably by doing the same thing we’re doing
here: deleting the old X and creating a new one of the right class. (There might be
other meaningful ways of handling the exception, but they’d be more application-
specific.)

The other possibility is that nobody handles the exception. We could just declare
"assignment operators shall always be called with like classes on either side of the
equal sign" as a program invariant. In other words, we declare heterogeneous
assignment to be a condition which Should Never Happen.

So then instead of the dynamic cast, you can do a static cast and precede it
with an assert:

So anyway, using the assert is one way around the heterogeneous-assignment

problem, and it has a lot to recommend it, in situations where you really know that
this invariant can hold.

But let’s go back to the previous answer for a minute and assume we’re going to
catch the exception and finagle the assignment in setX(). To refresh our
memory, setX() now looks like this:

3
If you need polymorphic copy on a group of related classes, you define a virtual function
called clone() and every class in the tree overrides it to call his own copy constructor. You can’t just
call X’s copy constructor for the same reason you can’t just call X’s assignment operator

79
Now, if x and newX are both instances of X or both instances of Y, we’re cool.
If x is an instance of Y and newX is an instance of X, we’re also cool.
Y::operator=() with throw a bad_cast exception, and we’ll catch it, delete x, and
new up a fresh new Y to assign to x.

But what if x is an instance of X and newX is an instance of Y? In this case, we’ll

end up in X’s assignment operator, and the dynamic cast will succeed. Y is a
subclass of X, so dynamically casting a reference to aY to a reference to an X is
legal. Every Y is also an X. But because we’re in X’s assignment operator, we’ll
only copy over the members of newX that were defined in X. It’s our old friend
slicing again.

What we’d have to do to avoid this is manually check for like class in each
assignment operator and throw the bad_cast ourselves, rather than relying
on dynamic_cast to do it for us.

Instead, my original solution to this problem was to avoid using the assignment
operator in the first place:

I still like this. It’s simple and clear, and it works correctly with no extra hassles
even when x and newX are instances of different classes. The other solution, with
the try/catch blocks, has an advantage in situations where the cost of deleting and
newing the destination object is large and relatively rare (the try costs nothing in
most modern compilers, so you in effect fast-path the case of like classes, but an
actual throw can be quite expensive, so you achieve this fast-path effect at the
expense of the different-classes case).

If the fast-path option makes sense for your application, I’d suggest avoiding the
exception and doing it yourself like this:

80
Now if you avoid using the assignment operator in situations where slicing may be
a problem, we’re still left with the question of whether it makes more sense to make
the assignment operator virtual or non-virtual. I’m tending now to come down on
the side of making the assignment operator virtual with an assert to check for the
different-classes condition (since there’s no way to handle that in the assignment
operator itself and therefore the calling function already has to be aware of the
possibility of polymorphism and handle it).

However, there’s another problem here. I remembered Taligent’s coding guidelines

discouraging virtual assignment operators, so I went back to see why it
recommended that. I wish I had done that before. It turns out Taligent’s guidelines
weren’t hard and fast on the subject. Instead they point out that defining

virtual X& Y::operator=(const X& that);

won’t keep the compiler from defining

Y& Y::operator=(const Y& that);

In other words, an override of an inherited assignment operator doesn’t suppress the

compiler-generated default assignment operator. You’d still have to do that
manually by declaring it private and not giving it an implementation.

And actually, this won’t even work because C++’s overload resolution rules will
cause the suppressed version to win in some types of call. For instance, consider a
class like this:

Now consider this code snippet:

81
 Since both someY and someOtherY are instances of Y, the overload resolution rules
will declare the nonvirtual version of operator=() to be the "winner," instead of the
inherited virtual operator=(). Since the nonvirtual operator=() is private, you’ll get
an access-violation error at compile time.

Instead, you’d have to define the default assignment operator to call the virtual one.
In every class that inherits the virtual one. Of course, this means defining it non-
virtual. To see why, imagine if Y in the above example had a subclass called Z.
If Y’s operator=() was virtual, Z would have to override it, then it would have to
override X’s operator=(), and then it would have to replace its own default
assignment operator. Cutting any corners here risks creating situations where the
"winning" function, according to the overload-resolution rules, is a function that is
not accessible or isn’t implemented. Clearly, this gets ridiculous quickly as the
inheritance hierarchy gets deeper.

One side effect in either case is that you have to define an override of the
virtual operator=() even when you don’t strictly need one; otherwise, the "default"
one will hide the virtual one.

So there you go. A truly foolproof method of handling polymorphism in assignment

operators involves declaring both a virtual and a non-virtual assignment operator in
every class (except the root class of each inheritance hierarchy), with the non-
virtual calling the virtual and the virtual asserting that both objects involved are the
same class. Any time a calling function couldn’t guarantee the invariant would hold,
it would have to avoid using the assignment operator and manually delete the object
referenced by the target variable and new up a new one of the proper type.

Summary:
1. In case of polymorphic class, we should define virtual assignment operator
if we need one.
2. Should we have virtual X& Y::operator=(const X& that); and/or virtual Y&
Y::operator=(const Y& that);
???
3. To avoid, heterogeneous-assignment problem we should use program
invariants.
Heterogeneous-assignments includes
 X=Y (slicing)
 X=Z (slicing)
 Y=X (partial assignment)
 Y=Z (dynamic_cast failure)
 Z=X (partial assignment) and
 Z=Y (dynamic_cast failure)

 Example
???

82
Copy Ctor vs Assignment operator
 The copy constructor and assignment operator do similar things. They both copy
state from one object to another, leaving them with equivalent semantic state.
 This doesn't necessarily mean that the objects are identical: some purely internal
data members (such as caches) might not be copied, or data members pointing to
other objects might end up pointing to different objects that are themselves
semantically equivalent, rather than pointing to the same objects.
 The difference between the copy constructor and assignment operator is that the
copy constructor is a constructor — a function whose job it is to turn raw storage
into an object of a specific class. An assignment operator, on the other hand, copies
state between two existing objects i.e. an assignment operator has to take into
account the current state of the object when copying the other object's state into it

Canonical form of a class

 A class which overloads four fundamental operators is in canonical form.
i. Constructor
ii. Destructor
iii. Copy Constructor
iv. Assignment Operator.
 If the constructor is trivial (i.e. there is no resource allocation) then we may not
have to overload four fundamental operators and the class itself is in canonical
form.
Example (Canonical form of a class)
class Person
{
public:
Person(char*, int);
Person(const Person&);
void Person::disp() const
~Person();
Person& operator=(const Person &rhs);
private:
char *name;
int age;
};
Person::Person(char* p,int x):age(x),name(new char[strlen(p)+ 1])
{
strcpy(name, p);
}

Person::~Person()
{
delete[] name;
}

Person::Person(const Person& rhs):

83
 name(new char[strlen(rhs.name) + 1]),age(rhs.age)
{
strcpy(name, rhs.name);
}
Person& Person::operator=(const Person &rhs)
{
// self assignment
if(this == &rhs)
return *this;
delete [] name;
name = new char[strlen(rhs.name) + 1];
strcpy(name, rhs.name);
age = rhs.age;
return *this;
}
void Person::disp() const
{
cout << "name : " << name << endl;
cout << "age : " << age << endl;
}
The above implementation will work perfectly but if we want to create an
array of Person objects on heap we have to support a default constructor.

The default constructor can be implemented in the following ways –

//1
Person::Person()
: age(0), name(NULL)
{
}

//2
Person::Person() : age(0), name(new char)
{
name[0] = '\0';
}
//3
Person::Person(): age(0), name(new char[1])
{
name[0] = '\0';
}
//1 Problem with the first case is if user creates and object and tries to call display,
the program may crash.

Example: -
Person b;
b.disp(); //b.disp() will fails because name is NULL;

84
 //2 In the Second case we are allocating memory for name in two different ways. In
default constructor we are considering name as a char pointer and in the other
constructor we are considering it as a pointer to an array of characters.
This creates a need for two destructors which is not possible.

//3. This is the ideal constructor for the class and does not require a specialize
destructor.

Composition (Containment, Aggregation, Embedding, Layering)

 An attribute of a class is itself an object of another class.
 Composition is basically relation between objects and generally its dynamic
relationship.
 It’s a reuse mechanism and its reuse per method.
 Its "has a" relationship

Friends

Friend functions
 Why friend functions
In order to allow an external function to have access to the private and protected
members of a class we have to declare the prototype of the external function that
will gain access preceded by the keyword friend within the class declaration that
shares its members.
For Example:-
???

 Important points about friend functions

 The keyword friend is placed only in the function declaration of the friend
function and not in the function definition.
 A Friend can access any member of the class to which it is a friend.
 It is possible to declare the friend function as either private or public.
 Friend is not a member of the class to which it is a friend.
 A member function can be invoked without the use of an object and it operates
on this object. The friend function has its argument as objects to operate on it.
 Seldom have friends i.e. friends should be avoided.
 It’s another interface for the class.

 Use friend functions in the following cases: -

i. Overloading binary operator and position of the operand is not at the right.
For Example: -
C2 = 3 + C1;

ii. Want to support traditional usage.

Example: -
MyClass Obj;

85
 Obj.Sq(); //Sq() is a member of MyClass
But if you want it to be traditional
Sq(Obj); //Sq() is a friend of MyClass

Member vs. friend implementation

 If the operation modifies the state of the class object, it operates on; it must be a
member function, not a friend function. Thus all operator such as =, *=, +=, etc are
naturally defined as member functions not friend functions.
 Conversely, if the operator does not modify any of its operands, but needs only
a representation of the object, it does not have to be a member function and often less
confusing. This is the reason why binary operators are often implemented as friend
functions such as + , *, -, etc.

Friend classes*** (???)

Why friend classes*** (???)

Important points about friend classes (???)

 When a class is declared as a friend, the friend class has access to the private data of
the class that made this a friend

Concept of friend and Nested class/Inner class

 Example (friend_inner_class.cpp)
//Hiding a class using Friend class
//List.h File
//may not be a complete implementation
#ifndef __LIST__
#define __LIST__
//avoid multiple inclusions in the same translation
//implementation class
//client should not know about this class
class Node
{
int val;
Node* link;
Node(int val) : val(val), link(0) { }
friend class List; // friend class
};

class List
{
private:
Node *head;
public:
List() : head(0) { }

86
 void make(int);
void disp() const;
//requires assignment, copy ctor & dtor ...
};
#endif

//List.cpp
#include "List.h"
void List::make(int n)
{
//create a list of n nodes
Node *t;
int val;
while(n--)
{
cin >>val;
t = new Node(val);
//put it in the list
t->link = head;
head = t;
}
}
void List::disp() const
{
Node *t = head;
while(t)
{
cout << t->val << endl;
t = t->link;
}
}
//Client Code
int main()
{
List l;
l.make(4);
l.disp();
}

//Implementation2 (Hiding a class using Sub class)

//List.h
#ifndef __LIST__
#define __LIST__
//Avoid multiple inclusions in the same translation
class List
{
class Node
{

87
 public:
int val;
Node* link;
Node(int val) : val(val), link(0) { }
};

private:
Node *head;
public:
List() : head(0) { }
void make(int);
void disp() const;
//requires assignment, copy ctor & dtor ...
};
#endif

//Discussion:
1. Client should not know about the Node class as we may change our mind later
on to use something else instead of Node. So Node class has everything as
private and List is made friend of Node so that it can access Node’s members.
2. It is clear that friend function is an interface concept
3. Friend class is an implementation concept which hides a class. For example
Node is hidden class.
4. Another way of hiding a class is to use nested classes
5. If the implementation class (Node) is not a nested class, it should have all its
members as private so that client code does not know about it.
In this case the user class (List) will be the friend of implementation class so
that it can use it.
6. If the class is nested then client code cannot create its instances so there is no
need to make members private and the other class as a friend of it.

 Be careful when using friend functions and classes, because it allows the friend
function or class to violate encapsulation. If the details of the class change, the
details of the friend will also be forced to change.

Reducing recompilation***
Read Large Scale C++ Software Design
???

88
Functions ***

Function arguments & return values

 If you are passing objects by value, specifying const has no meaning to the
client (it means that the passed argument cannot be modified inside the
function).
You can specify that function arguments are const when passing them by value,
such as
void f1(const int i)
{
i++; // Illegal -- compile-time error
}
Actually you’re making a promise that the original value of the variable will not be
changed by the function f1( ). However, because the argument is passed by value,
you immediately make a copy of the original variable, so the promise to the client
is implicitly kept. Inside the function, the const takes on meaning: the argument
cannot be changed. So it’s really a tool for the creator of the function, and not
the caller.
To avoid confusion to the caller, you can make the argument a const inside the
function, rather than in the argument list.
void f2(int ic)
{
const int& i = ic;
i++; // Illegal -- compile-time error
}
 If you are returning an object of a user-defined type by value as a const, it
means the returned value cannot be modified
If you say that a function’s return value is const:
const int g();
You are promising that the original variable (inside the function frame) will not be
modified. And again, because you’re returning it by value, it’s copied so the original
value could never be modified via the return value. At first, this can make the
specification of const seem meaningless. You can see the apparent lack of effect of
returning consts by value in this example:
//Constval.cpp
//Returning consts by value has no meaning for built-in types
int f3()
{
return 1;
}
const int f4()
{
return 1;
}
int main()
{
const int j = f3(); // Works fine
int k = f4(); // But this works fine too!

89
}
For built-in types, it doesn’t matter whether you return by value as a const, so you
should avoid confusing the client programmer and leave off the const when
returning a built-in type by value.
Returning by value as a const becomes important when you’re dealing with user-
defined types. If a function returns a class object by value as a const, the return
value of that function cannot be an lvalue (that is, it cannot be assigned to or
otherwise modified). For example:
//: C08:ConstReturnValues.cpp
// Constant return by value
//Result cannot be used as an lvalue
class X
{
int i;
public:
X(int ii = 0);
void modify();
};
X::X(int ii) { i = ii; }
void X::modify() { i++; }
X f5()
{
return X();
}

const X f6()
{
return X();
}
void f7(X& x)
{ // Pass by non-const reference
x.modify();
}
int main()
{
f5() = X(1); // OK -- non-const return value
f5().modify(); // OK
// Causes compile-time errors:
//! f7(f5());
//! f6() = X(1);
//! f6().modify();
//! f7(f6());
}
Sometimes, during the evaluation of an expression, the compiler must create
temporary objects and they’re automatically const
In the above example, f5( ) returns a non-constX object. But in the expression:
f7(f5()); the compiler must manufacture a temporary object to hold the return value
of f5( ) so it can be passed to f7( ). This would be fine if f7( ) took its argument by

90
 value; then the temporary would be copied into f7( ) and it wouldn’t matter what
happened to the temporary X. However, f7( ) takes its argument by reference, which
means in this example takes the address of the temporary X. Since f7( ) doesn’t take
its argument by const reference, it has permission to modify the temporary object.
But the compiler knows that the
temporary will vanish as soon as the expression evaluation is complete, and thus
any modifications you make to the temporary X will be lost. By making all
temporary objects automatically const, this situation causes a compile-time error so
you don’t get caught by what would be a very difficult bug to find.

Thus, it’s important to use const when returning an object by value if you want
to prevent its use as an lvalue.
 If you are passing and returning addresses, const is a promise that the
destination of the address will not be changed
 Example
//ConstPointer.cpp
//Constant pointer arg/return
void t(int*) {}
void u(const int* cip)
{
//! *cip = 2; // Illegal -- modifies value
int i = *cip; // OK -- copies value
//! int* ip2 = cip; // Illegal: non-const
}
const char* v()
{
// Returns address of static character array:
return "result of function v()";
}
const int* const w()
{
static int i;
return &i;
}
int main()
{
int x = 0;
int* ip = &x;
const int* cip = &x;
t(ip); // OK
//! t(cip); // Not OK
u(ip); // OK
u(cip); // Also OK
//! char* cp = v(); // Not OK
const char* ccp = v(); // OK
//! int* ip2 = w(); // Not OK
const int* const ccip = w(); // OK
const int* cip2 = w(); // OK

91
 //! *w() = 1; // Not OK
}

Default values
 Client can introduce default values.
 Default arguments to a function can be different in different scopes.
Example: -
//file1.h
int sum(int, int, int = 0);

//file1.cpp
int sum(int x , int y, int z)
{
return x + y + z;
}

//main.cpp
int main()
{
int sum(int, int, int = 10);
int a(10), b(20);
cout << sum(a, b) << endl;
}
Here call to sum is converted to sum(10,20,10) instead of sum(10,20,0);Because in the
main scope default argument is 10.
 Defaults can be built over number of stat
Example
//file1.h
int sum(int, int, int = 0);

//file1.cpp
int sum(int x , int y, int z)
{
return x + y + z;
}
//main.cpp
int main()
{
int sum(int, int, int = 10);
int sum(int, int = 20 int);
int a(10), b(20);
cout << sum(111) << endl;
}
Here sum(111) is valid statement and converted to sum(111,20,10);
 Only one scope is used at a time
Example: -

//file1.h

92
 int sum(int, int, int = 0);

//file1.cpp
int sum(int x , int y, int z)
{
return x + y + z;
}
//main.cpp
int main()
{
int sum(int, int = 20 int);
int a(10), b(20);
cout << sum(111) << endl;
}
Here sum(111) will not compile as in the current scope (i.e. scope of main) sum has
only one default parameter;

Function prototypes
 Match arguments to parameters (#, order, type of arguments should match those of
parameters; if possible will do conversions)
 Overloading
 Holding default values

Function calls***
 Order of evaluation of arguments: - All arguments are evaluated before the function
is called but the order is not defined.
 Calling convention( __stdcall)
i. This is to indicate the calling convention which is used to call Win32 API
functions.
ii. The callee cleans the stack, so the compiler makes var arg functions __cdecl.
iii. Functions that use this calling convention require a function prototype.
iv. The following list shows the implementation of this calling convention:
Argument-passing order Right to left
Argument-passing By value, unless a pointer or reference
convention type is passed.
Stack-maintenance Called function pops its own arguments
responsibility from the stack.
Name-decoration convention An underscore (_) is prefixed to the name.
The name is followed by the “at” sign (@)
followed by the number of bytes (in
decimal) in the argument list. Therefore,
the function declared as int func( int a,
double b ) is decorated as follows:
_func@12

Resolution of function calls***

 A match call is resolved.
 More than one match : ambiguity; erro
93
 No match in all 6 steps : error
 The six steps are: -
i. Exact match / trivial conversion
a. Variable to const
b. Array to pointer
c. Derived class object to base class object.
ii. Generic fn : templates
iii. Promotion
a. integral type => int
b. floating type => double without loss of precision
iv. std conversion
a. any numeric type => any other numeric type may be, with loss of
precision
v. user defined conversion
a. Single argument constructor.
b. Type conversion operator.
vi. type unsafe conversion
void* => any other pointer type

Function pointers and call back technique***

Function pointers
 Once a function is compiled and loaded into the computer to be executed, it
occupies a chunk of memory. That memory, and thus the function, has an address.
 A function name is actually the starting address of the function code.
 A function pointer holds the address of a function, just like a float pointer holds the
address of a float variable.
 A function pointer can point to either a global function or a class function.

Defining a function pointer

 To define a pointer to a function that has no arguments and no return value, you say:
void (*funcPtr)();
 Complicated examples
//ComplicatedDefinitions.cpp
/* 1. */ void * (*(*fp1)(int))[10];
/* 2. */ float (*(*fp2)(int,int,float))(int);
/* 3. */ typedef double (*(*(*fp3)())[10])();
fp3 a;
/* 4. */ int (*(*f4())[10])();
int main() {}

Number 1 says “fp1 is a pointer to a function that takes an integer argument and
returns a pointer to an array of 10 void pointers.”

94
 Number 2 says “fp2 is a pointer to a function that takes three arguments (int, int,
and float) and returns a pointer to a function that takes an integer argument and
returns a float.”
Number 3 says “fp3 is a pointer to a function that takes no arguments and returns a
pointer to an array of 10 pointers to functions that take no arguments and return
doubles.”
Number 4 is a function declaration instead of a variable definition. It says “f4 is a
function that returns a pointer to an array of 10 pointers to functions that return
integers.”

Global function pointer Example:

95
Class method pointer Example

96
Why use pointers to functions*** (???)
 Functions as Arguments to Other Functions: If you were to write a sort routine,
you might want to allow the function's caller to choose the order in which the data
is sorted. One way to let your user specify what to do is to provide a flag as an
argument to the function, but this is inflexible; the sort function allows only a fixed
set of comparison types (e.g., ascending and descending).
A much nicer way of allowing the user to choose how to sort the data is simply to
let the user pass in a function to the sort function. This function might take two
pieces of data and perform a comparison on them. We'll look at the syntax for this
in a bit.
Example:
#include <iostream>
#include <algorithm> // for swap
// Note our user-defined comparison is the third parameter
void SelectionSort(int *anArray, int nSize, bool (*pComparison)(int, int))
{
using namespace std;
for (int nStartIndex= 0; nStartIndex < nSize; nStartIndex++)
{
int nBestIndex = nStartIndex;
// Search through every element starting at nStartIndex+1
for (int nCurrentIndex = nStartIndex + 1; nCurrentIndex < nSize;
nCurrentIndex++)
{
// Note that we are using the user-defined comparison here
if (pComparison(anArray[nCurrentIndex], anArray[nBestIndex])) //
COMPARISON DONE HERE
nBestIndex = nCurrentIndex;
}
// Swap our start element with our best element
swap(anArray[nStartIndex], anArray[nBestIndex]);
}
}
// Here is a comparison function that sorts in ascending order
// (Note: it's exactly the same as the previous Ascending() function)
bool Ascending(int nX, int nY)
{
return nY > nX;
}
// Here is a comparison function that sorts in descending order
bool Descending(int nX, int nY)
{
return nY < nX;
}
bool EvensFirst(int nX, int nY)
{
// if nX is not even and nY is, nY goes first
if ((nX % 2) && !(nY % 2))
97
 return false;
// if nX is even and nY is not, nX goes first
if (!(nX % 2) && (nY % 2))
return true;
// otherwise sort in Ascending order
return Ascending(nX, nY);
}
// This function prints out the values in the array
void PrintArray(int *pArray, int nSize)
{
using namespace std;
for (int iii=0; iii < nSize; iii++)
cout << pArray[iii] << " ";
cout << endl;
}
int main()
{
int anArray[9] = { 3, 7, 9, 5, 6, 1, 8, 2, 4 };
// Sort the array in descending order using the Descending() function
SelectionSort(anArray, 9, Descending);
PrintArray(anArray, 9);
// Sort the array in ascending order using the Ascending() function
SelectionSort(anArray, 9, Ascending);
PrintArray(anArray, 9);

SelectionSort(anArray, 9, EvensFirst);
PrintArray(anArray, 9);
return 0;
}

 Callback Functions***
????

Call back technique

 Callback technique is an effort to separate “what” from “how”. When you want
your program to be applicable to different use cases, you may find that at a certain
point in your program, you need to invoke a function which has the same signature
but different implementation for different use cases. In other words, for every
specific case, the type of information passed to and returned by that function (which
represents “what”) is the same, but the implementation of the function (which
represents “how”) is different. Different client (who uses your program) may have
different implementations.
 In this case, you have to provide a mechanism so that the client may register his
own version of that function to your program before the invoking point, so that your
program knows which one to call. This technique is called “callback”.
 There are three ways to achieve call-back.

98
  The OO approach of callback is to let the client class inherit from and
implement an interface. In your code you simply hold an interface pointer and
call the interface methods through that pointer. The client program will create
his implementation object; assign its pointer to the interface pointer in your
class before the calling pointer in your class is reached.
 However, if the client class is already finished and did not implement the
interface you want, you have to use a less OO approach. The client programmer
(or your do it for him) should write a separate matching class for the client
class, which inherit from the desired interface with the function you will call
back, which provides the service you need by manipulating client-class objects.
In your code you have a pointer to the interface and invoke the service provided
by the separate class.
 The least OO approach is to use function pointers like the above example.

Using Polymorphism and Virtual Functions Instead of Function Pointers***

 You can often avoid the need for explicit function pointers by using virtual
functions. For instance, you could write a sorting routine that takes a pointer to a
class that provides a virtual function called compare:
 Example
class Sorter
{
public:
virtual int compare (const void *first, const void *second);
};
// cpp_qsort, a qsort using C++ features like virtual functions
void cpp_qsort(void *base, size_t nmemb, size_t size, Sorter *compar);

Inside cpp_qsort, whenever a comparison is needed, compar->compare should be

called. For classes that override this virtual function, the sort routine will get the
new behavior of that function. For instance:

class AscendSorter : public Sorter

{

virtual int compare (const void*, const void*)

{
int first = *(int*)first_arg;
int second = *(int*)second_arg;
if ( first < second )
{
return -1;
}
else if ( first == second )
{
return 0;
}

99
 else
{
return 1;
}
}
};
Virtual functions are implemented behind the scenes using function pointers, so
you really are using function pointers--it just happens that the compiler makes the
work easier for you. Using polymorphism can be an appropriate strategy (for
instance, it's used by Java), but it does lead to the overhead of having to create an
object rather than simply pass in a function pointer.

Function overloading

 Make the client life easier having more than one function with the same name
 Based on argument to parameter matching and not the return type
 No special linker is required as the call is resolved at compile time
 Function names are unique for the linker; Made possible by name mangling /
decoration
 Name mangling depends on the compiler so all translations to be compiled using
the same compiler
 Overloading on return values not possible as you can call a function and ignore
the return value (that is, you can call the function for its side effects).
 Overloaded functions should be in the same scope.
 If client code calls an overloaded function, then compiler proceeds in the
following way: -
i. Searches for the exact match
ii. if a match is found, checks for the accessibility
For example if we have three overloaded members as follows
fun(double) //private
fun(int) //private
fun(char) //public
If fun(10) is called, there will be a compiler error; as compiler does not go back to
find the next match.
 Type-safe Linkage
 The C++ compiler refuses to declare a function automatically for you, so it’s likely
that you will include the appropriate header file. However, if for some reason you
still manage to misdeclare a function, either by declaring by hand or including the
wrong header file (perhaps one that is out of date), the name decoration provides a
safety net that is often referred to as type-safe linkage.
//Def.cpp {O}
//Function definition
void f(int) {}

In the second file, the function is misdeclared and then called:

//Use.cpp
//{L} Def

100
 // Function misdeclaration
void f(char);
int main() {
f(1); // Causes a linker error
}
Even though you can see that the function is actually f(int), the compiler doesn’t
know this because it was told – through an explicit declaration – that the function is
f(char). Thus, the compilation is successful
The linker will fail because the compiler decorates the names, the definition
becomes something like f_int, whereas the use of the function is f_char. When the
linker tries to resolve the reference to f_char, it can only find f_int, and it gives you
an error message.
 const overloading:-
 When you have an inspector method and a mutator method with the same name and
the same number and type of parameters — the methods differ only in that one is
const and the other is non-const
 The subscript operator is a common use of const-overloading.

When you apply the subscript operator to a MyFredList object that is non-const, the
compiler will call the non-const subscript operator. Since that returns a normal
Fred&, you can both inspect and mutate the corresponding Fred object.
However when you apply the subscript operator to a const MyFredList object, the
compiler will call the const subscript operator. Since that returns a Fred const&, you
can inspect the corresponding Fred object, but you can't mutate/change it:
 A copy constructor can be overloaded based on const overloading.
 STL containers use const overloading :-
i. A const overloaded begin() and end() function to decide whether to return a
const_iterator or a normal iterator
ii. std::map::operator[] is also overloaded on const. The const version throws
an error if you try to reference an invalid key, but the non-const version does
an insert.

Finding the Address of an Overloaded Function*** (???)

Function Overriding

 Overriding is modification of base class behavior in the derived class.

 Inheritance hierarchy is required
 Function signature should be same however return type can be related by
inheritance

101
 For example:
virtual Base& operator= (const Base& s);
virtual Derived& operator= (const Base& s);

Function Overloading vs. Overriding

 Overriding is in the different scopes but overloading is in the same scope.
 Virtual
 dispatch : dynamic

Operator overloading
Which operators cannot be overloaded and why
 You can redefine or overload the function of most built-in operators in C++. These
operators can be overloaded globally or on a class-by-class basis. Overloaded
operators are implemented as functions and can be member functions or global
functions.
 You can overload any of the following operators:

+ - * / % ^ & | ~
! = < > += -= *= /= %=
^= &= |= << >> <<= >>= == !=
<= >= && || ++ -- , ->* ->
() [] new delete new[] delete[]

 You can overload both the unary and binary forms of the following operators:

+ - * &

Restrictions

 You cannot overload the preprocessor symbols # and ##.

 New operators such as **, <>, or &| cannot be created
 You cannot change the precedence, grouping, or the number of operands of an
operator.
 An overloaded operator (except for the function call operator) cannot have default
arguments or an ellipsis in the argument list.
 You must declare the overloaded =, [], (), and -> operators as non-static member
functions to ensure that they receive lvalues as their first operands.
 Most of the operators can be overloaded except these:-
Dot(.), scope resolution (::), sizeof(), ?: conditional

. (Member access) .* (Member access through :: (Scope ?: (Ternary

102
 pointer to member) resolution) conditional)

 We can’t overload these relational operators (&&, || and , (comma) because they
support short circuit4 evaluation but we can’t do that if we overload these operators
 We can’t change the precedence so the operators call c1 + c2 * c3 will be converted
as follows: -
(c1.operator+(c2)) .operator*(c3) //NO
c1.operator+((c2) .operator*(c3)) //YES

 We can’t change the associativity so the operators call c1 / c2 / c3 will be converted

as follows: -
(c1.operator/(c2)) .operator/(c3) //YES
c1.operator/((c2) .operator/(c3)) //NO

 We can’t change the arity

c1 ++ c2 //NO

Why friends in operator overloading

 Example (operator_overloading_friend_functions.cpp)
 Statement P1 is straightforward
 In case of P2 the statement c3 = c1 + 5.6 is converted to the operator function call
because 5.6 is converted to an implicit call to single argument constructor of the
complex.
If you want to avoid such implicit conversion use explicit keyword with single
argument constructor.
 In P3 the statement c3 = 5.6 + c1 cannot be executed with the above
implementation of complex. To do this there are two options to modify the
operator+ implementation: -
i. Implement operator+ as a C function (i.e. not as a member of the class) and
introduce get methods to get the values of rhs and lhs.
Complex operator+(const Complex& lhs, const Complex& rhs)
{
return Complex(lhs.getrp() + rhs.getrp(), lhs.getip() + hs.getip());
}
This is not a good solution as accessor functions are not considered good.
If we use accessor functions we are exposing the type of variables to client and
we may decide to change their type later which will affect the client code and
ideally the client code should not be affected if the server code is changed.

ii. Make operator+, a friend of Complex class

//Declaration

//Implementation

4
If an operator supports short circuit evaluation it means
i) Evaluation proceeds left to right
ii) Evaluation stops as soon as the result is known

103
 With this operator function both P1 and P3 are valid in the client code so we
don’t need the earlier implementation of operator+
In this implementation we need to consider the following situations:-
In the above operator+ implementation we are retuning an object of Complex:-
1. Is it possible to it return by ref?
//NO; As it’s a local object

2. Can this object be a Static object so that we can return it by ref?

//No; Why not???

3. Can this object be a dynamic object?

//No; because in that case we shall be putting a responsibility on the client
code to delete that object

 To support P4 type of statements in client code we have overloaded << operator as

friend of Complex.
We need to consider the following: -
1. Can operator<< function be a member of ostream?
//Not helpful as we shall not be able to access private //members (ip and rp) of
Complex in that case

2. Can operator<< function be a member function of Complex class?

//Not helpful as the position of Object is not at the right. So we cannot
consider //why not use c3 >> cout; Fine But how about c1 >> c2 >> cout;
impossible

3. Can operator<< function be a friend of ostream class?

//Not required; as we are not interested in the private //members of ostream

4. Can operator<< function be a friend of complex;

//fine

5. Can operator<< function be a friend of ostream & complex both.

//Not required to make it a friend of ostream

6. Consider the declaration of operator<<

Explanation
i. Why Complex Object reference as const?
We don’t want to modify Complex object.
ii. Why returning ostream object by reference.
We want to allow cascading.
iii. Why not returning ostream object by const reference
We want to allow cascading and in that case we shall be modifying the
ostream object.
104
Overloading insertion and extraction operators (<< and >>)
 These operators are implemented as friend functions.
Example:
friend ostream& operator<< (ostream&, const Complex&);
friend istream& operator>> (istream&, const Complex&);

Overloading Subscript operator

 The subscript operator can have two possible prototypes
int operator[](int); //NO
int& operator[](int); //YES
If it’s implemented with the first prototype, it cannot support
XObj[i] = val
 Also the subscript operator comes in pair to support the mutator and inspector.
const int& operator[](int) const; //inspector
int& operator[](int); //mutator

Overloading function call operator***

 Object supporting function call operators are called Functors.
 The function call operator, when overloaded, doesn’t modify how functions are
called. Rather it modifies how the operator is to be interpreted when applied to
objects of a given type.
 We overload the function call operator, operator(), with a non-static member
function that has any number of parameters. Its declaration will have the following
form: -

return_type operator()(parameter_list);

 Unlike all other overloaded operators, you can provide default arguments and
ellipses in the argument list for the function call operator.
Example
class A
{
public:
...

void operator()(int a, char b, ...){ }

void operator()(char c, int d = 20) { }
};
int main()
{
A a;
a(5, 'z', 'a', 0);
a('z');
//a();
}
 Example (subscript operator for Matrix class)
(matrix.cpp)

105
Type Conversion operators***

 A Conversion operator can be thought of as a user-defined type casting operator.

 It converts its object to a different type in contexts that require that specific type.
The conversion is done automatically.
 Conversion operators can convert their objects to any given type, fundamental and
user defined alike.
 Conversion operators differ from ordinary operators in two ways: -
 A Conversion operator has no return value (not even void). The return value is
inferred from the operator’s name
 A Conversion operator takes no arguments.
Example: (TypeConversion.cpp)
class BDate
{
public:
BDate(int date = 1, int month = 1) : date(date), month(month)
{
}
void disp() const
{
cout << "bday : " << date << " : " << month << endl;
}
private:
int date, month;
};

class Date
{
public:
// epoch date in UNIX
Date(int = 1, int = 1, int = 1970);
// return type implied; cannot be specified
operator int() const;
operator BDate() const;
Date operator++(int); //post
Date& operator++(); //Pre
friend ostream& operator<<(ostream&, const Date&);
friend bool operator<(const Date&, const Date&);
private:
int dd, mm, yy;
};
Date::Date(int dd, int mm, int yy): dd(dd), mm(mm), yy(yy)
{
}
Date::operator int() const
{

106
 return dd;
}
Date::operator BDate() const
{
return BDate(dd, mm);
}
//Requires two objects and two copy ctor calls
Date Date::operator ++(int)
{
Date t(*this);
// logic to change to date
++dd;
return t;
}
//No overheads
Date& Date::operator ++()
{
// logic to change to date
++dd;
return *this;
}
ostream& operator<<(ostream& o, const Date& d)
{
return o << d.dd << "-" << d.mm << "-" << d.yy << endl;
}
bool operator<(const Date& l, const Date& r)
{
if(l.yy > r.yy)
return false;
else if(l.yy == r.yy && l.mm > r.mm)
return false;
else if(l.yy == r.yy && l.mm == r.mm && l.dd >= r.dd )
return false;
else
return true;
}

template<typename T> void disp(T x[], int n)

{
for(int i = 0; i < n; ++i)
cout << x[i] << endl;
}

//To use myswap() T : needs to implement

//copy ctor
//Assignment op
template<typename T> void myswap(T& x, T& y)
{

107
 T t = x;
x = y;
y = t;
}
//To use mysort()T needs to support relational operator: <
template<typename T> void mysort(T x[], int n)
{
int i, j;
for(i = 0; i < n - 1; ++i)
for(j = i + 1; j < n; ++j)
if(x[j] < x[i])
myswap(x[i], x[j]);
}

Inheritance & Composition***

(Especially order of Ctor, Dtor, multiple inheritances, virtual inheritance, structure of
object in case of virtual inheritance, RTTI in Multiple Inheritance etc.)
 Inheritance is
 basically a relation (Static relationship) between classes
 “is a” or “has a” relationship
 In a derived class, we get
 Attributes of the base class.
 Behavior of the base class.
 In the derived class we
 Can add attributes
 Can add behavior
 Modify behavior
 We can’t drop an attribute
 We can’t drop a behavior
 A derived class can be used anywhere the base class is expected. However, a base
class CANNOT be used anywhere the derived class is expected.
 These member of base are not inherited in the derived class:-
 The constructor and destructor of a base class are not inherited. Therefore the
derived class constructors & destructor need to be called in inilization list.
 The assignment operator is not inherited
 The friend functions and friend classes of the base class are also not inherited.
 Even though the private members of the base class are not accessible from derived
classes, they are inherited in derived class. The reason is that the public and
protected methods of the base class can still access private variables of the base
class, and these methods are available in the derived class.
 Inheritance supports property of substitution: - It should be possible to replace an
object of base class by an object of derived
 Behavior of the base class is also behavior of the derived
 Derived class object has an object of base class within it
 Object of a class can only be initialized by calling the constructor.
 The right way to initialize the base members is to call the base constructor in
the initialization list.

108
 If you have a class derived from a base class and try to initialize your base class
members in the derived constructor; you can’t do so (compiler error) even if the
base class members are public.
 Also calling base class’s constructor explicitly in the derived constructor wouldn’t
help as that will create a temporary object.
Example
//showing the right way of calling base constructor
class Base
{
public:
Base(int xx, int yy) : x(xx), y(yy)
{
cout << "Ctor of Base" << endl;
}
Base (): x(11), y(22)
{
cout << "Default Ctor of Base" << endl;
}
~Base()
{
cout << "Dtor of Base" << endl;
}
int x, y;
};
class Derived : public Base
{
public:
//The Right way of calling base Ctor
Derived(int x1, int y1, int z1) : z(z1), P2D(x1, y1)
{
cout << "Ctor of derived" << endl;
cout << x << "\t" << y << "\t" << z << endl;
}
int z;
};
 Constructor invocation order in the inheritance hierarchy:-
i. Client code creates an object of derived class
ii. Constructor of derived class is invoked.
iii. Initialization list of derived class constructor
iv. Constructors of base classes are invoked in the order of inheritance.
v. The member of the current class are initialize in the order of declaration
vi. Body of the derived class constructor.
vii. Back to client code

 Destructor invocation order:-

Multilevel Inheritance destructor invocation example

If I have the following hierarchy:

109
Class F contains member objects of type (Class E and Class D, declared in that
order)
Class F inherits the concrete class Class C
Class C inherits the abstract/pure virtual class Class B
Class B inherits the concrete class class A

If the destructor for object of type Class F is called, the following happen in the
below order:

Class F (the most derived) destructor is called and finishes

Class D (member object 2) destructor is called and finishes
Class E (member object 1) destructor is called and finishes
Class C (base of F) destructor is called and finishes
Class B (virtual, base of C) destructor is called and finishes
Class A (base of B, which is base of C) destructor is called and finishes

Multiple Inheritance destructor invocation example

class A {
public:
A(){
cout << "Ctor A" << endl;
}
~A()
{
cout << "Dtor A" << endl;
}
virtual void f()
{
cout << "A::f" << endl;
}
};
class B {
public:
B()
{
cout << "Ctor B" << endl;
}
~B()
{
cout << "Dtor B" << endl;
}
virtual void f()
{
cout << "B::f" << endl;
}
};
class C : public A ,public B {
public:

110
 C(){
cout << "Ctor C" << endl;
}
~C(){
cout << "Dtor C" << endl;
}
void f()
{
cout << "C::f" << endl;
}
};

int main(int argc, char **argv)

{
C* pc = new C;
pc->f();
pc->A::f(); //this calls f() from class A
pc->B::f(); //this calls f() from class B
delete pc;
}

Public, private and protected inheritance

Public inheritance
 All public members of the base class are accessible as public members of the
derived class and all protected members of the base class are accessible as protected
members of the derived class (private members of the base are never accessible
unless friended)

111
 Public inheritance models the subtyping relationship of object-oriented
programming: the derived class object IS-A base class object
 References and pointers to a derived object (DerivedPtr) are expected to be usable
by any code that expects references or pointers to any of its public bases

Protected inheritance
 All public and protected members of the base class are accessible as protected
members of the derived class (private members of the base are never accessible
unless friended)
 Protected inheritance may be used for "controlled polymorphism": within the
members of Derived, as well as within the members of all further-derived classes,
the derived class IS-A base: references and pointers to Derived may be used where
references and pointers to Base are expected
 Rarely useful. Used in boost::compressed_pair to derive from empty classes and
save memory using empty base class optimization (example below doesn't use
template to keep being at the point):

Private inheritance
 All public and protected members of the base class are accessible as private
members of the derived class (private members of the base are never accessible
unless friended).
 Private inheritance is commonly used in policy-based design, since policies are
usually empty classes, and using them as bases both enables static polymorphism
and leverages empty-base optimization
 Private inheritance can also be used to implement the composition relationship (the
base class subobject is an implementation detail of the derived class object). Using
a member offers better encapsulation and is generally preferred unless the derived
class requires access to protected members (including constructors) of the base,
needs to override a virtual member of the base, needs the base to be constructed
before and destructed after some other base subobject, needs to share a virtual base
or needs to control the construction of a virtual base. Use of members to implement
composition is also not applicable in the case of multiple inheritance from a
parameter pack or when the identities of the base classes are determined at compile
time through template metaprogramming.

112
 Similar to protected inheritance, private inheritance may also be used for controlled
polymorphism: within the members of the derived (but not within further-derived
classes), derived IS-A base.

 The usage of the base class is only for implementing the derived class. Useful with
traits and if size matters (empty traits that only contain functions will make use of
the empty base class optimization). Often containment is the better solution, though.
The size for strings is critical, so it's an often seen usage here

Multilevel and multiple inheritances

Multlevel Inheritance
Example

Shape

TwoDimensional ThreeDimensional
Shape Shape

113
Cube
Multiple Inheritance
 Deriving directly from more than one class is usually called multiple inheritance.
 This concept complicates the design and debuggers can have a hard time with it,
 Multiple Inheritance Example

 Multiple inheritance introduces a lot of issues:-

o Creation of compile time ambiguities when multiple base classes contain a
member with the same name. This problem can be solved by explicitly
specifying the version you need to use (using scope resolution)
The potential for naming conflicts increases exponentially as you inherit
more classes, and each of these naming conflicts needs to be resolved
explicitly.
o The diamond problem :- This occurs when a class (D) multiply inherits from
two classes (B & C) which each inherit from a single base class (A)

If the derived classes (B & C) override the same method from the base
class when calling the method from the merged class (D) and the joining
class does also override that method, an ambiguity will rise.
A second problem that can occur with the diamond pattern is that if the
two classes derived from the same base class, and that base class has one or
more members, then those members will be duplicated in the joining class.
This problem is solved with virtual inheritance.

114
 o Example :- iostream library objects std::cin and std::cout are both
implemented using multiple inheritance

Virtual inheritance***
 Virtual inheritance is used in multiple inheritance, where a particular base class in
an inheritance hierarchy is declared to share its member data instances with any
other inclusions of that same base in further derived classes.
 This can be used to avoid the diamond problem by clarifying ambiguity over which
ancestor class to use, as from the perspective of the deriving class (C in the example
above) the virtual base (X) acts as though it were the direct base class of C, not a
class derived indirectly through its base
 Example

115
Virtual functions
 Normal function calls are resolved at compile time; based on the type of the pointer
(or reference) and not based on the value of the pointer(or reference) whereas the
virtual function calls are resolved at run time; not based on type of pointer(or
reference) rather based on value of pointer(or reference).
 Virtual function : Overheads
i. A table per class (Virtual table)
ii. A pointer per object (vptr)
iii. Extra dereferencing at runtime.
 Derived class pointer (&DerObj) to base class pointer (pBase) is trivial conversion
but we can only access interface of Base class through pBase.
 Can a virtual function be inline?
YES
 Where in memory the virtual tables are stored?
May be Data Segment
 If you have your code in a .h and .cpp file where the virtual table will be put?
As a rule the virtual table is put where the destructor is defined.

Templates
 A template is a C++ entity that defines one of the following:
o A family of classes (class template), which may be nested classes
o A family of functions (function template), which may be member functions
o An alias to a family of types (alias template) (since C++11)
o A family of variables (variable template) (since C++14)
 Templates are parametrized by one or more template parameters, of three kinds:-
o Type template parameters,
o Non-type template parameters, and
o Template template parameters.
 A template can take one or more type parameters which are the symbols that
currently represent unspecified types.
For example:

Here, any_data_type is a template parameter, also referred as type parameter.

Another example:

Here any_data_type and p are template parameters.

 Type passed as parameter at compile time so templates are compile time

mechanism

116
 Function templates result in overloading of functions. If algorithm is same, use
templates otherwise overloading.
 Expansion per type and not per call
 When template arguments are provided or deduced (for function templates only),
they are substituted for the template parameters to obtain a specialization of the
template, that is, a specific type or a specific function lvalue. Specializations may
also be provided explicitly: full specializations are allowed for both class and
function templates, partial specializations are only allowed for class templates.
 Instantiation
o When a class/function template specialization is referenced, the template is
instantiated (the code for it is actually compiled), only if the template was
not already explicitly specialized or explicitly instantiated.
o Instantiation of a class template doesn't instantiate any of its member
functions unless they are also used.
o At link time, identical instantiations generated by different translation units
are merged.
 A template is not compiled once to generate code usable for any type; instead, it is
compiled for each type or combination of types for which it is used. This leads to an
important problem in the handling of templates in practice: You must have the
implementation of a template function available when you call it, so that you can
compile the function for your specific type. Therefore, the only portable way of
using templates at the moment is to implement them in header files by using
inline functions5

Explicit Initialization for Fundamental Types

 If you use the syntax of an explicit constructor call without arguments, fundamental
types are initialized with zero:

int i1; //undefined value

int i2 = int(); //initialized with zero
This feature is provided to enable you to write template code that ensures that
values of any type have a certain default value. For example, in the following
function the initialization guarantees that x is initialized with zero for
fundamental types:

template <class T> void f()

{
T x = T();
...
}

Template parameters and template arguments

5
To avoid the problem of templates having to be present in header files, the standard introduced a
template compilation model with the keyword export. However, I have not seen it implemented yet.

117
 Templates are parametrized by one or more template parameters, of three kinds:-
o Type template parameters,
o Non-type template parameters, and
o Template template parameters.
Example:

 In order for a template to be instantiated, every template parameter (type, non-type,

or template) must be replaced by a corresponding template argument.
 If an argument can be interpreted as a both a type-id and an expression, it is always
interpreted as a type-id, even if the corresponding template parameter is non-type:

Non-type template parameters/arguments

 In addition to type parameters, it is also possible to use Non-type parameters. A
Non-type parameter is then considered as part of the type.
 The standard allows the below, for non-type template parameters
o integral or enumeration type
o Pointer to object/function
o lvalue reference to object or lvalue reference to function
o Pointer to member
o std::nullptr_t

 The following limitations apply when instantiating templates that have non-type
template parameters:
 integral or enumeration type :- The template argument provided
(expression or integral type) must be a converted constant expression of the
template parameter’s type (so certain implicit conversions apply)
 Pointer to object: - The template arguments have to designate the address
of an object with static storage duration and a linkage (either internal or
external), or a constant expression that evaluates to the appropriate null
pointer or std::nullptr_t value.
 Pointer to function: - The valid arguments are pointers to functions with
linkage (or constant expressions that evaluate to null pointer values).
 lvalue reference to object or lvalue reference to function:- The argument
provided at instantiation cannot be a temporary, an unnamed lvalue, or a
named lvalue with no linkage

118
  Pointer to member:- The argument has to be a pointer to member
expressed as &Class::Member or a constant expression that evaluates to null
pointer or std::nullptr_t value
In particular, this implies that these cannot be used as template arguments to
instantiate templates whose corresponding non-type template parameters are
pointers to objects.
o string literals,
o addresses of array elements, and
o addresses of non-static members
 A template argument that can be used with a non-type template parameter
must be any converted constant expression, whose value can be determined at
compile time.
 Such arguments must be:
o Constant expressions
o Addresses of functions or objects with external linkage, or
o Addresses of static class members
Non-constant expressions can't be parsed and substituted during compile-time. They
could change during runtime, which would require the generation of a new template
during runtime, which isn't possible because templates are a compile-time
concept.
Example

 The value of integral argument should be known at compile time, this means
when being instantiated, only compile time constant integer can be passed. This
means 100, 100+99, 1<<3 etc. are allowed, since they are compiled time constant
expressions. Arguments, that involve function call, like abs (-120), are not allowed.
 Types such as float, double and string literals are not allowed as non type template
parameters. Floats/doubles etc. may be allowed, if they can be converted to
integer.
 Non-type template parameters of reference and pointer type cannot refer to/be the
address of
o A subobject (including non-static class member, base subobject, or array
element);
o A temporary object (including one created during reference initialization)
o A string literal

119
 o The result of typeid
o The predefined variable __func__.

Example: Non template type parameters

120
Template type arguments
 A template argument for a type template parameter must be a type-id, which may
name an incomplete type:

Template template arguments

 A template argument for a template template parameter must be an id-expression
which names a class template or a template alias.
 When the argument is a class template, only the primary template is considered
when matching the parameter.
 The partial specializations, if any, are only considered when a specialization based
on this template template parameter happens to be instantiated.

 To match a template template argument A to a template template parameter P, each

of the template parameters of A must match corresponding template parameters of
P. If P's parameter list includes a parameter pack, zero or more template parameters
(or parameter packs) from A's template parameter list are matched by it.

121
Default argument for template parameter
 Defaults can be specified for any kind of template parameter (type, non-type, or
template), but not to parameter packs
 Default parameters are not allowed
o in the out-of-class definition of a member template (they have to be
provided in the declaration inside the class body)
o n friend class template declarations
 On a friend function template declaration, default template arguments are allowed
only if the declaration is a definition, and no other declarations of this function
appear in this translation unit.
 Default template arguments that appear in the declarations and the definition are
merged similarly to default function arguments:

 But the same parameter cannot be given default arguments twice in the same scope

 The template parameter lists of template template parameters can have their own
default arguments, which are only in effect where the template template parameter
itself is in scope:

122
 Member access for the names used in a default template parameter is checked at the
declaration, not at the point of use:

 The default template argument is implicitly instantiated when the value of that
default argument is needed, except if the template is used to name a function:

Class Templates
 A class template describes a set of related classes or data types that differ only
 By types,
 By integral values,
 By pointers or references to variables with global linkage, or
 By a combination thereof
 Class templates are particularly useful in describing generic, but type-safe, data
structures.
 Classes, functions, variables, and member template specializations can be explicitly
instantiated from their templates. However, member functions, member classes, and
static data members of class templates can be explicitly instantiated from their
member definitions.
 Only the declaration is required to be visible when explicitly instantiating a function
template, a variable template, a member function or static data member of a class

123
 template, or a member function template. However, the complete definition must
appear before the explicit instantiation of a class template, a member class of a class
template, or a member class template, unless an explicit specialization with the
same template arguments appeared before.
 If a function template, variable template, member function template, or member
function or static data member of a class template is explicitly instantiated with an
explicit instantiation definition, the template definition must be present in the same
translation unit.
 When an explicit instantiation names a class template specialization, it serves as an
explicit instantiation of the same kind (declaration or definition) of each of its non-
inherited non-template members that has not been previously explicitly specialized
in the translation unit. If this explicit instantiation is a definition, it is also an
explicit instantiation definition only for the members that have been defined at this
point.
 Explicit instantiation definitions ignore member access specifiers: parameter types
and return types may be private.
 Implicit instantiation occurs when code refers to a template in context that
requires a completely defined type, or when the completeness of the type affects the
code, and this particular type has not been explicitly instantiated. For example,
when an object of this type is constructed, but not when a pointer to this type is
constructed.
This applies to the members of the class template: unless the member is used in the
program, it is not instantiated, and does not require a definition.

 If a class template has been declared, but not defined, at the point of instantiation,
the instantiation yields an incomplete class type:

 Local classes and any templates used in their members are instantiated as part of the
instantiation of the entity within which the local class or enumeration is declared.

Template Static Data Member

 The definition of a template static data member consists of the template parameter
specification followed by a variable definition, where the variable identifier is
qualified by the class template name and its template actual arguments.
 Example

124
Using Non-type (standard) parameters
 Like, function templates, class templates also can have both type parameter and
Non-type parameter (expression parameters).
 When an ordinary type is used as parameter, the template argument must be a
constant or a constant expression of an integral type.
 The standard allows the below, for non-type template parameters
 integral or enumeration type,
 pointer to object or pointer to function,
 lvalue reference to object or lvalue reference to function,
 pointer to member,
 std::nullptr_t.
 Besides the constant expressions, the only other arguments allowed are: -
 A pointer to a non-overloaded member,
 Addresses of functions or objects with external linkage, or
 Addresses of static class members.
 For example you can make a fixed-size Stack by specifying a non-type parameter
as the dimension for the underlying array, as follows:-

 The bitset class template is the only class in the STL that uses a Non-type template
parameter (which specifies the number of bits the bitset object can hold).

Using Default arguments with template classes

 Templates classes may have default arguments.
For example, the following declaration allows one to declare objects of class
MyClass with one or two template arguments

Note that default template arguments may be defined in terms of previous

arguments.

125
Nested Template Classes
 Nested classes may also be templates:

Class template deduction***

http://en.cppreference.com/w/cpp/language/class_template_deduction#Explicit_deducti
on_guides

Function template
 A function template defines a family of functions.

Instantiation of function template

Explicit instantiation
 Specify a list of types
 In the call before parentheses ()

(1) Explicit instantiation definition (without template argument deduction if every

non-default template parameter is explicitly specified)
(2) Explicit instantiation definition with template argument deduction for all
parameters
(3) Explicit instantiation declaration (without template argument deduction if
every non-default template parameter is explicitly specified)
(4) Explicit instantiation declaration with template argument deduction for all
parameters
 An explicit instantiation definition forces instantiation of the function or member
function they refer to.
 It may appear in the program anywhere after the template definition, and for a given
argument-list, is only allowed to appear once in the program.
 An explicit instantiation declaration (an extern template) prevents implicit
instantiations: the code that would otherwise cause an implicit instantiation has to
use the explicit instantiation definition provided somewhere else in the program.
 A trailing template-argument can be left unspecified in an explicit instantiation of a
function template specialization or of a member function template specialization if
it can be deduced from the function parameter

126
 Explicit instantiation of a function template or of a member function of a class
template cannot use inline or constexpr. If the declaration of the explicit
instantiation names an implicitly-declared special member function, the program is
ill-formed.
 Explicit instantiation declarations do not suppress the implicit instantiation of inline
functions, auto-declarations, references, and class template specializations. (thus,
when the inline function that is a subject of explicit instantiation declaration is
ODR-used, it is implicitly instantiated for inlining, but its out-of-line copy is not
generated in this TU)
 Explicit instantiation definition of a function template with default arguments is not
a use of the arguments, and does not attempt to initialize them:

Implicit instantiation
 Based on match of arguments to parameters
 Implicit instantiation occurs, when code refers to a function in context that requires
the function definition to exist, and this particular function has not been explicitly
instantiated. The list of template arguments does not have to be supplied if it can be
deduced from context

Example: -

127
Template argument deduction
 In order to instantiate a function template, every template argument must be known,
but not every template argument has to be specified. When possible, the compiler
will deduce the missing template arguments from the function arguments. This
occurs when a function call is attempted and when an address of a function template
is taken.

This mechanism makes it possible to use template operators, since there is no

syntax to specify template arguments for an operator other than by re-writing it as a
function call expression.

 Template argument deduction takes place after the function template name lookup
(which may involve argument-dependent lookup) and before overload resolution.

Explicit template arguments

 Template arguments of a function template may be obtained from

128
 o template argument deduction
o default template arguments
o specified explicitly, which can be done in the following contexts:
 in a function call expression
 when an address of a function is taken
 when a reference to function is initialized
 when a pointer to member function is formed
 in an explicit specialization
 in an explicit instantiation
 in a friend declaration
 There is no way to explicitly specify template arguments to overloaded operators,
conversion functions, and constructors, because they are called without the use of
the function name.
 The specified template arguments must match the template parameters in kind (i.e.,
type for type, non-type for non-type, and template for template)
 The specified non-type arguments must either match the types of the corresponding
non-type template parameters, or be convertible to them.
 The function parameters that do not participate in template argument deduction (e.g.
if the corresponding template arguments are explicitly specified) are subject to
implicit conversions to the type of the corresponding function parameter (as in the
usual overload resolution).

Template argument substitution

 When all template arguments have been specified, deduced or obtained from default
template arguments, every use of a template parameter in the function parameter list
is replaced with the corresponding template arguments.
 Substitution failure (that is, failure to replace template parameters with the deduced
or provided template arguments) of a function template removes the function
template from the overload set. This allows a number of ways to manipulate
overload sets using template metaprogramming. See SFINAE for details
 After substitution, all function parameters of array and function type are adjusted to
pointers and all top-level cv-qualifiers are dropped from function parameters (as in
a regular function declaration).
 The removal of the top-level cv-qualifiers does not affect the type of the parameter
as it appears within the function:

129
Function template specialization???

Explict Specialization
 Even though a generic function overloads itself as needed, you can explicitly
overload one, too. This is formally called explicit specialization.
 Explicit specialization allows customizing the template code for a given set of
template arguments.
 If you overload a generic function, that overloaded function overrides (or "hides")
the generic function relative to that specific version.
 Explicit specialization of a template allows you to tailor a version of a generic
function to accommodate a unique situation—perhaps to take advantage of some
performance boost that applies to only one type of data, for example.
 Example

 Any of the following can be fully specialized:

o function template

130
 o class template
o variable template (since C++14)
o member function of a class template
o static data member of a class template
o member class of a class template
o member enumeration of a class template
o member class template of a class or class template
o member function template of a class or class template
 Explicit specialization can only appear at namespace scope, in the same namespace
as the primary template (or in the nearest enclosing namespace if the primary is a
member template), and it has to appear after the non-specialized template
declaration. It is always in the scope of that namespace:

 Specialization must be declared before the first use that would cause implicit
instantiation, in every translation unit where such use occurs:

 A template specialization that was declared but not defined can be used just like any
other incomplete type (e.g. pointers and references to it may be used)


 When specializing a function template, its template arguments can be omitted if

template argument deduction can provide them from the function arguments:

 ??? http://en.cppreference.com/w/cpp/language

131


Function template overloading???

 In addition to creating explicit, overloaded versions of a generic function, you can
also overload the template specification itself.
 To do so, simply create another version of the template that differs from any others
in its parameter list.
 For example:

------------------------------------------------------------
 Function templates and non-template functions may be overloaded.
 A non-template function is always distinct from a template specialization with the
same type.
 Specializations of different function templates are always distinct from each other
even if they have the same type.
 Two function templates with the same return type and the same parameter list are
distinct and can be distinguished with explicit template argument list.
 When an expression that uses type or non-type template parameters appears in the
function parameter list or in the return type, that expression remains a part of the
function template signature for the purpose of overloading:
 Example

 Two expressions involving template parameters are called equivalent if two

function definitions that contain these expressions would be the same under ODR
rules, that is, the two expressions contain the same sequence of tokens whose names
are resolved to same entities via name lookup, except template parameters may be
differently named.

 When determining if two dependent expressions are equivalent, only the dependent
names involved are considered, not the results of name lookup. If multiple
declarations of the same template differ in the result of name lookup, the first such
declaration is used:
132
 Two function templates are considered equivalent if
o they are declared in the same scope
o they have the same name
o they have identical template parameter lists
o the expressions involving template parameters in their return types and
parameter lists are equivalent
 Two expressions involving template parameters are called functionally equivalent if
they are not equivalent, but for any given set of template arguments, the evaluation
of the two expressions results in the same value.
 Two function templates are considered functionally equivalent if they are
equivalent, except that one or more expressions that involve template parameters in
their return types and parameter lists are functionally equivalent
 If a program contains declarations of function templates that are functionally
equivalent but not equivalent, the program is ill-formed; no diagnostic is required.

 When the same function template specialization matches more than one overloaded
function template (this often results from template argument deduction), partial
ordering of overloaded function templates is performed to select the best match.
Specifically, partial ordering takes place in the following situations:
o Overload resolution for a call to a function template specialization
???
o When the address of a function template specialization is taken
???
o When a placement operator delete that is a function template specialization
is selected to match a placement operator new
???
o When a friend function declaration, an explicit instantiation, or an explicit
specialization refers to a function template specialization
???

133
 http://en.cppreference.com/w/cpp/language/function_template
------------------------------------------------------------

Class Member template

 Template declarations (class, function, and variables (since C++14)) can appear
inside a member specification of any class, struct, or union that aren't local
classes.

 Partial specializations of member template may appear both at class scope and at
enclosing namespace scope, but explicit specializations may only appear at
enclosing namespace scope.

 If the enclosing class declaration is, in turn, a class template, when a member
template is defined outside of the class body, it takes two sets of template
parameters: one for the enclosing class, and another one for itself:

134
Member function templates
 Member functions of classes may be templates

Here, declares a set of member functions

for parameters of any type. You can pass any argument as long as its type provides
all operations used by fun()
This feature is often used to support automatic type conversions for members in
template classes.
 Destructors and copy constructors cannot be templates. If a template constructor
is declared which could be instantiated with the type signature of a copy
constructor, the implicitly-declared copy constructor is used instead
 A member function template cannot be virtual, and a member function template
in a derived class cannot override a virtual member function from the base class.
Templates are all about the compiler generating code at compile-time. Virtual functions
are all about the run-time system figuring out which function to call at run-time.
Once the run-time system figured out it would need to call a templatized virtual function,
compilation is all done and the compiler cannot generate the appropriate instance
anymore. Therefore, you cannot have virtual member function templates

 A non-template member function and a template member function with the same
name may be declared. In case of conflict (when some template specialization
matches the non-template function signature exactly), use of that name and type
refers to the non-template member unless an explicit template argument list is
supplied.

135
 An out-of-class definition of a member function template must be equivalent to the
declaration inside the class (see function template overloading for the definition of
equivalency), otherwise it is considered to be an overload.

Conversion function templates (Templates and automatic type conversions)

 Member functions of classes may be templates

Here, declares a set of member functions

for parameters of any type. You can pass any argument as long as its type provides
all operations used by fun()
This feature is often used to support automatic type conversions for members in
template classes.
For example, in the following definition the argument x of assign() must have
exactly the same type as the object it is called for:

136
It would be an error to use different template types for the objects of the assign ()
operation even if an automatic type conversion from one type to the other is
provided:

By providing a different template type for the member function, you relax the rule
of exact match. The member template function argument may have any template
type, then as long as the types are assignable:

Note that the argument x of assign() now differs from the type of *this. Thus, you
can't access private and protected members of MyClass<> directly. Instead, you
have to use something like getValue() in this example.

Example:

137
 STL Example
The structure pair is defined in <utility> as follows:
The template version of a copy constructor provided here is used when implicit type
conversions are necessary. If an object of type pair gets copied, the normal
implicitly generated default copy constructor is called

 A user-defined conversion function can be a template.

138
 During overload resolution, specializations of conversion function templates are not
found by name lookup. Instead, all visible conversion function templates are
considered, and every specialization produced by template argument deduction
(which has special rules for conversion function templates) is used as if found by
name lookup.
 Using-declarations in derived classes cannot refer to specializations of template
conversion functions from base classes.
 A user-defined conversion function template cannot have a deduced return type

Member variable template

 Until variable templates were introduced in C++14, parametrized variables were
typically implemented as either static data members of class templates or as
constexpr function templates returning the desired values.
 A variable template defines a family of variables or static data members.

variable-declaration - A declaration of a variable. The declared variable name

becomes a template name.
parameter-list - A non-empty comma-separated list of the template parameters, each
of which is either non-type parameter, a type parameter, a template parameter,
or a parameter pack of any of those.
 A variable template may be introduced by a template declaration at namespace
scope, where declaration declares a variable.

139
 When used at class scope, variable template declares a static data member template.

 As with other static members, a definition of a static data member template may be
required. Such definition is provided outside the class definition. A template
declaration of a static data member at namespace scope may also be a definition of
a non-template data member of a class template:

 Unless a variable template was explicitly specialized or explicitly instantiated, it is

implicitly instantiated when a specialization of the variable template is used.
 Default template argument of a variable template is implicitly instantiated when the
variable template is used in the context that requires the value of the argument.
 Variable templates cannot be used as template template arguments.

Template constructors
 Template constructors are usually provided to enable implicit type conversions
when objects are copied
 Note that a template constructor does not hide the implicit copy constructor. If the
type matches exactly, the implicit copy constructor is generated and called.
 Thus, if you write a template constructor, don't forget to provide a copy constructor,
if the default copy constructor does not fit your needs
 If you declare any constructor (including a template one), the compiler will refrain
from declaring a default constructor.
 Unless you declare a copy-constructor (for class X one that takes X or X& or X
const &) the compiler will generate the default copy-constructor.

140
 If you provide a template constructor (for class X which takes T const & or T or
T&) then the compiler will nevertheless generate a default non-template copy-
constructor, even though you may think that it shouldn't because when T = X the
declaration matches the copy-constructor declaration.
 In the latter case you may want to provide a non-template copy-constructor along
with the template one. They will not conflict. When X is passed the non-template
will be called. Otherwise the template
 A special form of a member template is a template constructor. Template
constructors are usually provided to enable implicit type conversions when objects
are copied. Note that a template constructor does not hide the implicit copy
constructor. If the type matches exactly, the implicit copy constructor is generated
and called.
For example

Here, the type of xd2 is the same as the type of xd, so it is initialized via the built-in
copy constructor. The type of xi differs from the type of xd, so it is initialized by
using the template constructor. Thus, if you write a template constructor, don't
forget to provide a copy constructor, if the default copy constructor does not fit
your needs.

 Example

141
Template Specialization
 Template specialization lets templates deal with special cases. Sometimes a generic
algorithm can work much more efficiently for a certain kind of sequence (for
example, when given random-access iterators), and so it makes sense to specialize it
for that case while using the slower but more generic approach for all other cases.
 Performance is a common reason to specialize, but it's not the only one; for
example, you might also specialize a template to work with certain objects that
don't conform to the normal interface expected by the generic template.
 These special cases can be handled using two forms of template specialization:

Explicit (full) template specialization

 Allows customizing the template code for a given set of template arguments.

142
 Any of the following can be fully specialized:
o function template
o class template
o variable template (since C++14)
o member function of a class template
o static data member of a class template
o member class of a class template
o member enumeration of a class template
o member class template of a class or class template
o member function template of a class or class template
 Explicit specialization lets you write a specific implementation for a particular
combination of template parameters.
Example: - Explicit template specialization

In the above example, if the specialization of eq does not exist for the char* the last
call to eq() instantiate a char* version of the template function and always returns
that the x and y are not same which is a wrong result.
So we have added a specialized version of eq() to compare char*
 Explicit specialization can only appear at namespace scope, in the same namespace
as the primary template (or in the nearest enclosing namespace if the primary is a
member template), and it has to appear after the non-specialized template
declaration. It is always in the scope of that namespace:

 Specialization must be declared before the first use that would cause implicit
instantiation, in every translation unit where such use occurs:

143
 A template specialization that was declared but not defined can be used just like any
other incomplete type (e.g. pointers and references to it may be used)

Explicit specializations of function templates

 When specializing a function template, its template arguments can be omitted if
template argument deduction can provide them from the function arguments:

 A function with the same name and the same argument list as a specialization is not
a specialization (see template overloading in function_template)
 An explicit specialization of a function template is inline only if it is declared with
the inline specifier (or defined as deleted), it doesn't matter if the primary template
is inline.
 Default function arguments cannot be specified in explicit specializations of
function templates, member function templates, and member functions of class
templates when the class is implicitly instantiated.
 An explicit specialization cannot be a friend declaration.
 If the primary template has a exception specification that isn't noexcept(false), the
explicit specializations must have a compatible exception specification.

Members of specializations
 When defining a member of an explicitly specialized class template outside the
body of the class, the syntax template <> is not used, except if it's a member of an
explicitly specialized member class template, which is specialized as a class
template, because otherwise, the syntax would require such definition to begin with
template<parameters> required by the nested template

144
 An explicit specialization of a static data member of a template is a definition if the
declaration includes an initializer; otherwise, it is a declaration. These definitions
must use braces for default initialization:

 A member or a member template of a class template may be explicitly specialized

for a given implicit instantiation of the class template, even if the member or
member template is defined in the class template definition.

145
 Member or a member template may be nested within many enclosing class
templates. In an explicit specialization for such a member, there's a template<> for
every enclosing class template that is explicitly specialized.

 In such a nested declaration, some of the levels may remain unspecialized (except
that it can't specialize a class member template if its enclosing class is
unspecialized). For each of those levels, the declaration needs
template<arguments>, because such specializations are themselves templates:

146
Partial template specialization
 Allows customizing class templates for a given category of template arguments.
 For class templates only, you can define partial specializations that don't have to
fix all of the primary (unspecialized) class template's parameters
 Syntax

Where className identifies the name of a previously declared class template. This
declaration must be in the same namespace or, for member templates, class scope as
the primary template definition which it specializes.
 Example

147
 Declarations 2 to 5 declare partial specializations of the primary template. The
compiler will then choose the appropriate template.

 Examples of partial specializations in the standard library include std::unique_ptr,

which has a partial specialization for array types.

The argument list

 The following restrictions apply to the argument-list of a partial template
specialization:
1. The argument list cannot be identical to the non-specialized argument list (it
must specialize something)

Moreover, the specialization has to be more specialized than the primary

template

2. Default arguments cannot appear in the argument list

3. If any argument is a pack expansion, it must be the last argument in the list
4. Non-type argument expression cannot use the name of the template
parameter except when it is exactly the name of the template parameter
(until C++14). Non-type argument expressions can use template parameters
as long as the parameter appears at least once outside a non-deduced context
(since C++14)

5. Non-type template argument cannot specialize a template parameter whose

type depends on a parameter of the specialization:

148
Name lookup
 Partial template specializations are not found by name lookup. Only if the primary
template is found by name lookup, its partial specializations are considered. In
particular, a using declaration that makes a primary template visible, makes partial
specializations visible as well:

Partial ordering
 When a class template is instantiated, and there are partial specializations available,
the compiler has to decide if the primary template is going to be used or one of its
partial specializations.
1. If only one specialization matches the template arguments, that
specialization is used
2. If more than one specialization matches, partial order rules are used to
determine which specialization is more specialized. The most specialized
specialization is used, if it is unique (if it is not unique, the program cannot
be compiled)
3. If no specializations match, the primary template is used

 To establish more-specialized-than relationship between partial specializations, each

is first converted to a fictitious function template as follows:
o The first function template has the same template parameters as the first
partial specialization and has just one function parameter, whose type is a
class template specialization with all the template arguments from the first
partial specialization
o The second function template has the same template parameters as the
second partial specialization and has just one function parameter whose type

149
 is a class template specialization with all the template arguments from the
second partial specialization.
The function templates are then ranked as if for function template overloading.

Members of partial specializations

 The template parameter list and the template argument list of a member of a partial
specialization must match the parameter list and the argument list of the partial
specialization.
 Just like with members of primary templates, they only need to be defined if used in
the program.
 Members of partial specializations are not related to the members of the primary
template.
 Explicit (full) specialization of a member of a partial specialization is declared the
same way as an explicit specialization of the primary template.

150
 If a class template is a member of another class template, and it has partial
specializations, these specializations are members of the enclosing class template. If
the enclosing template is instantiated, the declarations of each member partial
specialization is instantiated as well (the same way declarations, but not definitions,
of all other members of a template are instantiated)
 If the primary member template is explicitly (fully) specialized for a given
(implicit) specialization of the enclosing class template, the partial specializations
of the member template are ignored for this specialization of the enclosing class
template.
 If a partial specialization of the member template is explicitly specialized for a
given (implicit) specialization of the enclosing class template, the primary member
template and its other partial specializations are still considered for this
specialization of the enclosing class template.

151
Function Template Overloading and specialization examples
 Function template overloading isn't the same thing as specialization, but it's related
to specialization
 Example: - Consider the following declarations:

There are two groups of overloaded f() here:

o Those that take a single (type or Non-type) parameter

o Those that take two parameters

Now let's consider each of the calls in turn:

Which of the above functions are invoked by each of the following? Be specific by
identifying the template parameter types, where appropriate.

152
 a. This calls #10, because it's an exact match for #10 and such non-templates are
always preferred over templates
b. This calls #8, because f<int> is being explicitly requested.
c. This calls #3 (T is int), because that is the best match.
d. This calls #2 (T is complex<double>), because no other f can match.
e. This calls #1 (T1 is int, T2 is float). You might think that #9 is very close -- and
it is -- but a non-template function is preferred only if it is an exact match.
f. This one does call #9, because now #9 is an exact match and the non-template is
preferred.
g. This calls #6 (T is complex<double>), because #6 is the closest overload. #6
provides an overload of f where the second parameter is a pointer to the same
type as the first parameter.
h. This calls #7 (T is double), because #7 is the closest overload.
i. This calls #5 (T is double). #5 provides an overload of f where the first
parameter is a pointer to the same type as the second parameter.
j. Clearly (by now), we're asking for #4 (T is double).
k. Several other overloads are close, but only #1 fits the bill here (T1 is double, T2
is int*).
l. This calls #3 (T is int*), which is the closest overload even though some of the
others explicitly mention a pointer parameter.

Friend and templates

Templates friends
 Both function template and class template declarations may appear with the friend
specifier in any non-local class or class template (although only function templates
may be defined within the class or class template that is granting friendship). In this
case, every specialization of the template becomes a friend, whether it is implicitly
instantiated, partially specialized, or explicitly specialized.

153
 Friend declarations cannot refer to partial specializations, but can refer to full
specializations:

 When a friend declaration refers to a full specialization of a function template, the

keyword inline and default arguments cannot be used.

 If a member of a class template A is declared to be a friend of a non-template class

B, the corresponding member of every specialization of A becomes a friend of B. If
A is explicitly specialized, as long as there is a member of the same name, same
kind (type, function, class template, function template), same parameters/signature,
it will be a friend of B.

154
 Default template arguments are only allowed on template friend declarations if the
declaration is a definition and no other declarations of this function template appear
in this translation unit.

Template friend operators

 A common use case for template friends is declaration of a non-member operator
overload that acts on a class template
e.g. operator<<(std::ostream&, const Foo<T>&) for some user-defined Foo<T>
Such operator can be defined in the class body, which has the effect of generating a
separate non-template operator<< for each T and makes that non-
template operator<< a friend of its Foo<T>

 or the function template has to be declared as a template before the class body, in
which case the friend declaration within Foo<T> can refer to the full specialization
of operator<< for its T:

155
 Example :- stream insertion and extraction operators are often declared as non-
member friends

156
Templates and multiple-file projects
 From the point of view of the compiler, templates are not normal functions or
classes. They are compiled on demand, meaning that the code of a template
function is not compiled until an instantiation with specific template arguments is
required. At that moment, when an instantiation is required, the compiler generates
a function specifically for those arguments from the template.
 When projects grow it is usual to split the code of a program in different source
code files. In these cases, the interface and implementation are generally separated.
Taking a library of functions as example, the interface generally consists of
declarations of the prototypes of all the functions that can be called. These are
generally declared in a "header file" with a .h extension, and the implementation
(the definition of these functions) is in an independent file with c++ code.
 Because templates are compiled when required, this forces a restriction for multi-
file projects: the implementation (definition) of a template class or function must be
in the same file as its declaration. That means that we cannot separate the interface
in a separate header file, and that we must include both interface and
implementation in any file that uses the templates.
 Since no code is generated until a template is instantiated when required, compilers
are prepared to allow the inclusion more than once of the same template file with
both declarations and definitions in a project without generating linkage errors.

Exception handling
 Code that you want to monitor for exceptions must have been executed from within
a try block. (Functions called from within a try block may also throw an
exception.)
 Exceptions that can be thrown by the monitored code are caught by a catch
statement, which immediately follows the try statement in which the exception was
thrown.
 An exception can be thrown from outside the try block as long as it is thrown by a
function that is called from within try block.
 A try block can be localized to a function. When this is the case, each time the
function is entered, the exception handling relative to that function is reset
 You can restrict the type of exceptions that a function can throw outside of itself. In
fact, you can also prevent a function from throwing any exceptions whatsoever. To
accomplish these restrictions, you must add a throw clause to a function definition.
The general form of this is shown here:
ret-type func-name(arg-list) throw(type-list)
{
// ...
}
 Attempting to throw an exception that is not supported by a function will cause the
standard library function unexpected() to be called. By default, this causes abort()
to be called, which causes abnormal program termination.
 There are five runtime error messages associated with exceptions:
 No handler for the exception
 Unexpected exception thrown
 An exception can only be re-thrown in a handler

157
  During stack unwinding, a destructor must handle its own exception
 Out of memory
When errors are detected at runtime, the error message displays the type of the
current exception and one of the five error messages. By default, the predefined
function terminate() is called, which then calls abort().

Fundamentals

Try block
 A try block contains the code which may throw the exception, or contains the code
that calls the method which may throw the exception.
Throw
 A throw keyword specifies an operand which can be of any type. The thrown
object can be a class object or just a character string:
 The throw statement is actually passing information to the exception handler in the
catch block. This information can be either only be the type of the thrown object –
in many cases it is enough, or plus the extra information carried in the thrown
object.
Throw point
 When an exception is thrown, the control leaves the try block and searches for a
catch block which can match this exception. If one catch block catches the
exception, the code included will be executed, then the control will resume to the
first statement after the last catch block. All codes between the throw point and the
last catch block will be skipped. The control has no way to return to the throw
point.
 If the exception is not caught, the method call stack is unwound and control will
further more exit to the outer scope and continue searching the following catch
blocks. If it is already the most outer block such as main, method terminate is
called, which by default will call method abort.
Catch block
 When exception happens, a temporary copy of the thrown object is created and
initialized. If the catch block has defined a parameter name of that type, this name
will be given to this temporary object and used to access the data members and
methods of the object. If the catch block does not have an parameter name, then the
thrown object’s internal information can not be accessed, and it is only used to
match the catch block. After handler finishes, the temporary object is destroyed.

What to throw
 Throw exceptions by value, and catch them by (usually const) reference. You
need to throw exceptions by value because the exception object will be destructed
when it goes out of scope (at the end of the basic block where it is caught -
unless you re-throw the original exception).
 If you throw a pointer to an allocated object, it will not be deleted and you will
leak memory.
 One might consider throwing an exception by reference. You would never throw
a reference to an allocated object as you will leak. But you could consider throwing
158
 a reference to a static object. You may not think you can throw a reference to a local
object but you can.
 Some Programmers throw pointers to static C string constants, e.g. throw
"bailed out"; this is not so bad in itself, because it does not leak memory.
But in the long run it is hard to ensure that only static constants are thrown; the
catch clause cannot discern the difference between a string that was compiled in and
a string you allocated.
Do not try to get around this by deleting a pointer that you have caught, as you
might have the opposite problem - you will crash if someone throws you the
address of some static memory

What to catch
 You should catch an exception by reference to avoid the slicing problem.
For example, when catching std::exception and its subclasses such as the ones
declared in <stdexcept>. If you catch std::exception by value and query its what()
method for a diagnostic message, you will likely get an unhelpful result like the
single word "exception". Had you caught it by reference you will get the intended
error message. It is helpful to subclass your own exception classes from
std::exception and override what() to provide custom diagnostics.
 You should generally catch by const reference, as this aids compiler optimization,
unless you will be calling methods on the exception that are not declared const.
 Catching by reference also avoids some overhead. Catching by value will not catch
the exception object itself, but a copy.
 Summary
The exception object that is passed to the catch clause is a copy of the object
that was thrown. This is meant to avoid the problem that would be caused by
the thrown object being destructed is it goes out of scope because of the
exception that is throwing it. Throwing a reference will still create a copy. The
only way to avoid this copy is to throw a pointer, but then you are faced with
the issue of whether and how to delete it.

Catch through inheritance

 Due to inheritance hierarchies, a derived-class object can be caught by a handler
specifying either the derived-class type or the base-class type.
 As a general rule, put the specific type handlers in the front, such as derived-class
type handlers, and put the generic handlers after, such as base-class type handlers,
and put “catch (...)” at the last. If you reverse the sequence, the exceptions will all
be caught by generic handlers and will never get to the specific ones.
 A “void *” handler will catch all exceptions of pointer type.

Release the Resource in catch Block

 When an exception happens, the try block terminates and all automatic objects
inside the try block are destroyed before the handler begins executing. However, it
is possible that some allocated resources are not yet released in the try block. The
catch handler, if possible, should release these resources, e.g., delete the space
allocated by new, and close any files opened in the try block.
 The handler must have access to the copy constructor of the thrown object. It
means that the header file of the thrown object should be included.

159
Exception Specification
 An exception specification (also called throw list) is throw followed by a list of
types enclosed in "( )":
 It can be placed after any method header, to restrict the kind of exceptions that can
be thrown by this method.
 All derived-class types based on the throw list types can also be thrown.
 If any exception not listed in the throw list is thrown, method unexpected is called,
which will call the method specified by method set_unexpected, or by default it
will call method terminate.
 Method terminate will call the method specified by method set_terminate, or by
default it will call method abort.
 Method set_unexpected and set_terminate take method names i.e. function pointer
as arguments. The methods must be with void return type and no arguments.
 Method set_unexpected and set_terminate returns the name of the method last
called by terminate or unexpected. This enables the programmer to save the name
and use it later.
 If the user-defined method specified in set_terminate or set_unexpected does not
exit the program, method abort will be automatically called to end the program
execution at last.
 If you include exception "std::bad_exception" (derived from base class
"exception" whose prototype is in header file <exception>) in the throw list of a
method, when unexpected throw happens, method unexpected will throw
"bad_exception" instead of calling terminate by default or user-defined method
specified by method set_unexpected.
 An empty throw list "throw" means that the method wouldn't throw any exception
without alerting method unexpected

Stack Unwinding
 When an exception is thrown but not caught in a certain scope, the method call
stack is unwound, which means that the method which thrown the exception
terminates, all local objects destroyed, then control returns to the point where this
method was called.
 If that calling point is in a try block, control will leave that try block and search the
following handlers. If that point is not in a try block or the search fails, stack
unwinding will happen again -- until it reaches main, and method terminate will be
called, as said before.
 As a general result, if you don’t provide any exception handling code and exception
happens, the program will be terminated. But if you provide a proper exception
handling measure, the program can go on working.
 Example

160
Exception Thrown from Constructor and Destructor
 When an exception is thrown in a constructor, destructors for all the local objects
created as part of the object being constructed will be called.
 If a destructor which is called to unwind the stack, throws out an exception, method
terminate will be called.
 Normally you should avoid throwing an exception out of a constructor without
catching it and doing necessary clean up in the constructor first. A simple solution is
to use default constructor to create a very "safe" model of object, then use another
method which is typically called "Init" in many applications to initialize it.
 When the exception is thrown from a constructor
i. The constructor is exited
ii. The dynamic memory allocated before the throw point, becomes memory
leak.
iii. The destructor of the class is not called, because a destructor is only called
for a fully constructed object, and because the constructor is half-way
terminated by the throwing of exception, the object is not fully constructed.
 The correct way to deal with such situation is
i. To catch possible exception in the constructor, and in the catch block, delete
all dynamic allocated resources, then rethrow the exception again as a
notification

161
 ii. Use auto_ptr< > to create local object; the destructor of auto_ptr< > will
delete the object pointed by the wrapped pointer when it goes out of scope.

Insufficient Memory when using new

 When new fails to obtain memory, older-version compilers will return 0. The
ANSI/ISO C++ draft standard version specifies that when new fails, it
automatically throws out a "std::bad_alloc" exception defined in header file
<new>. If you still want new to return 0, you have to put "(nothrow)" after new:

 If you pass the name of a user-defined function (which has void return type and no
arguments) as an argument to method "set_new_handler", whose header file is
<new>, then new will not throw the ”std::bad_alloc" exception. Instead it will call
that handler repeatedly until it successfully allocates memory. You can even
overload operator new and "set_new_handler" for the class in question.

Standard Library Exception Hierarchy

 All exceptions thrown from the language or the STL are derived from the base class
exception
 The base class "exception", whose header file is <exception>, offers the method
"what" to access the appropriate error message.

162
 Standard exception class hierarchy

Hierarchy of Standard Exceptions

 The standard exception classes can be divided into three groups

i. Exceptions for language support
 bad_alloc :- thrown by new when it fails to obtain memory
 bad_cast:- thrown by dynamic_cast.
 bad_typeid

ii. Exceptions for the C++ standard library (header <stdexcept>)

 These exception classes are usually derived from class logic_error
 An exception of class invalid_argument is used to report invalid
arguments, such as when a bitset (array of bits) is initialized with a char
other than '0' or '1'.
 An exception of class length_error is used to report an attempt to do
something that exceeds a maximum allowable size, such as appending
too many characters to a string.

163
  An exception of class out_of_range is used to report that an argument
value is not in the expected range, such as when a wrong index is used in
an array-like collection or string
 An exception of class domain_error is used to report a domain error. In
addition, for the I/O part of the library, a special exception class called
ios_base::failure is provided. It may be thrown when a stream changes
its state due to an error or end-of-file.

iii. Exceptions for errors outside the scope of a program (header

<stdexcept>)
 These exception classes are derived from runtime_error. These are
provided to report events that are beyond the scope of a program and are
not easily avoidable.
 An exception of class range_error is used to report a range error in
internal computations.
 An exception of class overflow_error is used to report an arithmetic
overflow
 An exception of class underflow_error is used to report an arithmetic
underflow.

MFC way of exception handling***

164
Input/Output Using Stream Classes (work on reducing the material)
(Especially class diagram and special functions like getch, getline and diff with normal
I/O functions)
Look into STL document

165
Standard Function Library
(Book Reference is “The Complete Reference C++ Chapter 25-31)
 C++ defines two types of libraries.
o The first is the standard function library. This library consists of general-
purpose, stand-alone functions that are not part of any class. The function
library is inherited from C.
o The second library is the object oriented class library.

The C-Based I/O Functions

http://www.cplusplus.com/reference/cstdio/

String and Character functions

http://www.cplusplus.com/reference/cctype/
http://www.cplusplus.com/reference/cstring/

Mathematical functions
http://www.cplusplus.com/reference/cmath/

Time Date and Localization functions

http://www.cplusplus.com/reference/ctime/
http://www.cplusplus.com/reference/clocale/

Dynamic Allocation functions

(Only Dynamic memory management)
http://www.cplusplus.com/reference/cstdlib/

Utility Functions
(All except Dynamic memory management)
http://www.cplusplus.com/reference/cstdlib/
http://www.cplusplus.com/reference/csignal/
http://www.cplusplus.com/reference/cassert/
http://www.cplusplus.com/reference/cstdarg/

Wide-Character Functions

The Wide-Character Classification Functions

http://www.cplusplus.com/reference/cwctype/

The Wide-Character I/O Functions

http://www.cplusplus.com/reference/cwchar/

166
Special topics

C++ Coding Style idioms???

http://stackoverflow.com/questions/276173/what-are-your-favorite-c-coding-style-
idioms/2034447#2034447

RAII: Resource Acquisition Is Initialization

Copy-swap Idiom
http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom

CRTP: Curiously Recurring Template Pattern

pImpl: Pointer-to-Implementation

Compile-time polymorphism

Template and Hook

The Problem with const Data Members???

http://www.drdobbs.com/the-problem-with-const-data-members/184403306

Cloning C++ class with pure virtual methods

Example:

167
memcpy is evil
 It's a C construct you should never use in C++. Never use memcpy() in C++ code
 memcpy() operates on bits and bytes, not on objects.
 It just looks ugly and forces you to be concerned with things you shouldn't need to
worry about, like the size of TBar.
 It fails to take into account what's actually being stored in the objects you're
copying, leading to erroneous results, or even uglier code that takes the special
cases into account.
 Example:
Consider an example assignment operator’s various implementation for a call TFoo
derived from TSuperFoo

Implementation 1:

The above code just copies the pointer values from one TFoo to the other. In other
words, it's an ugly way of doing

fBar1 = that.fBar1;
fBar2 = that.fBar2;

Implementation 2:

Closer to the mark, but ever scarier in terms of its results, is

memcpy(fBar1, that.fBar1, sizeof(TBar));
memcpy(fBar2, that.fBar2, sizeof(TBar));

This would copy the data members of that's TBars into this's TBars,
so this and that retain their own separate TBar objects.

The problem is that it bypasses the assignment operator and copy constructor
for TBar, so if TBar has any owning pointers6 of its own, you have the same
6
Owning pointer is a concept to manage memory effectively. Every object in the runtime environment,
there is one and only one pointer to it through which the object can be deleted. This pointer is an "owning
pointer," and the object or function containing that pointer is the object's "owner." All other pointers to
the object are called "aliasing pointers." The owner of the object expects to delete the object; objects with
aliasing pointers don't.

168
 problem. You'll also have problems if TBar owns locks or system resources that
need to be properly cleaned up or duplicated when you change the internal state of
the object. And, of course, if any of these pointers is NULL, you'll probably crash.

Using the asm Keyword???

Linkage Specification****Move from Here***

 Objects, references, functions, types, templates, and namespaces are all considered
names. A name can have one of three linkage types:

External linkage
 The linkage type of a name specifies its visibility from other scopes and translation
units. A name with external linkage can be referred to from every translation unit of
the program. Examples of such names include ordinary functions that aren't
explicitly declared as static, global objects, const objects explicitly declared extern,
classes, enumerations and their enumerators, templates, namespaces, and so on.
Here are a few examples of names with external linkage:
 Example:
int n; //global non-static, hence external linkage
class C
{
void f(); // member functions
static int n; // static data members
};
extern const K; //defined in a different translation unit
void func ();
namespace NS
{
class D{}; // qualified name NS::D has external linkage
}
enum DIR
{
Up,
Down
}
// DIR, Up, and Down have external linkage

Internal linkage
 A name with internal linkage is visible only from within the translation unit in
which it was declared. A name declared in a namespace scope (that is, declared
globally or within a namespace) has internal linkage if it's the name of a static
object, a static function, a member of an anonymous union, a member of an
anonymous namespace, a typedef name, or a const object not declared extern. Here
are some examples of names with internal linkage:
static void f(); //a static function
static int q; //a static object declared in global scope
namespace //members of anonymous namespace
169
 {
class C{};
int x;
}
const M=1000; //const object not declared extern
union
{ //members of an anonymous union
int xxx;
float yyyy;
};
typedef int I; // typedef names

No linkage
 Names with no linkage are visible only in the scope in which they're declared. Such
names include local objects, local classes, and other local types. Put differently, any
name that has neither external linkage nor internal linkage has no linkage. Here are
some examples of such names:
int main()
{
class C{}; // C is a local class; has no linkage
int j; // local object not declared extern has no linkage
C c; // the object c has no linkage
enum Parity // local enum and enumerators
{
Even,
Odd
};
}

Array-Based I/O???

auto_ptrs
 The auto_ptr template class is designed to help manage memory in a semi-
automatic way and prevent memory leaks when unexpected events such as
exceptions would otherwise have caused the normal cleanup code to be skipped.
 An auto_ptr is a pointer that serves as owner of the object to which it refers (if any).
As a result, an object gets destroyed automatically when its auto_ptr gets destroyed.
A requirement of an auto_ptr is that its object has only one owner.
 Class auto_ptr<> does not allow you to initialize an object with an ordinary pointer
by using the assignment syntax. Thus, you must initialize the auto_ptr directly by
using its value

170
 The former creates a new object of type Y by using an explicit conversion from type
X, whereas the latter creates a new object of type Y by using an implicit conversion.

Transfer of Ownership by auto_ptr

 A transfer of ownership means that the value is not simply copied. In all cases of
ownership transfer, the previous owner loses its ownership. As a consequence the
previous owner has the null pointer as its value after the transfer.
 This is a significant violation of the general behavior of initializations and
assignments in programming languages. Here, the copy constructor modifies the
object that is used to initialize the new object, and the assignment operator
modifies the right-hand side of the assignment. It is up to the programmer to
ensure that an auto_ptr that lost ownership and got the null pointer as value is no
longer dereferenced.
 To assign a new value to an auto_ptr, this new value must be an auto_ptr. You
can't assign an ordinary pointer:

 The const auto_ptr Idiom: -

 The const auto_ptrs never lose ownership.
 Copying a const auto_ptr is illegal, and in fact the only things you can do
with a const auto_ptr are
o Dereference it with operator*() or operator->()
o Call get() to inquire about the value of the contained pointer.
This means that we have a clear and concise idiom to express that an
auto_ptr can never lose ownership.
 Example:

171
 The transfer of ownership implies a special use for auto_ptrs; that is, functions
can use them to transfer ownership to other functions. This can occur in two
different ways:
1. A function can behave as a sink of data. This happens if an auto_ptr is passed as
an argument to the function by value. In this case, the parameter of the called
function gets ownership of the auto_ptr. Thus, if the function does not transfer it
again, the object gets deleted on function exit:

2. A function can behave as a source of data. When an auto_ptr is returned,

ownership of the returned value gets transferred to the calling function. The
following example shows this technique:

 Caveat (auto_ptr in the parameter list or return value)

 The semantics of auto_ptr always include ownership, so don't use
auto_ptrs in a parameter list or as a return value if you don't mean to
transfer ownership. Consider, for example, the following naive
implementation of a function that prints the object to which an auto_ptr
refers.
Using it, would be a disaster.

172
 Whenever an auto_ptr is passed to this implementation of bad_print(), the
objects it owns (if any) are deleted. This is probably not the programmer's
intention and would result in fatal runtime errors:

 You might think about passing auto_ptrs by reference instead. However

that doesn’t guarantee that the ownership will not be transferred. For
example in case the called function assigns the source reference to another
auto_ptr the ownership will be transferred and the source object shall be
deleted.
In words of Nicolai M. Josuttis “However, passing auto_ptrs by
reference confuses the concept of ownership. A function that gets an
auto_ptr by reference might or might not transfer ownership. Allowing
an auto_ptr to pass by reference is very bad design and you should
always avoid it.”
Example:

173
 According to the concept of auto_ptrs, it is possible to transfer ownership
into a function by using a constant reference. This is very dangerous because
people usually expect that an object won't get modified when you pass it as
a constant reference. Fortunately, there was a late design decision that
made auto_ptrs less dangerous. By some tricky implementation
techniques, transfer of ownership is not possible with constant references.
In fact, you can't change the ownership of any constant auto_ptr:
Example:

174
This solution makes auto_ptrs safer than they were before. Many interfaces
use constant references to get values that they copy internally. In fact, all
container classes of the C++ standard library behave this way, which might look
like the following:

If such an assignment was possible for auto_ptrs, the assignment would

transfer ownership into the container. However, because of the actual
design of auto_ptrs, this call results in an error at compile time:

175
 All in all, constant auto_ptrs reduce the danger of an unintended transfer of
ownership. Whenever an object is passed via an auto_ptr, you can use a constant
auto_ptr to signal the end of the chain.
 For a const auto_ptr, the const does not mean that you can't change the value
of the object the auto_ptr owns (if any). You can't change the ownership of
a constant auto_ptr; however, you can change the value of the object to
which it refers. For example:

Whenever the const auto_ptr is passed or returned as an argument, any

attempt to assign a new object results in a compile-time error. With respect
to the constness, a const auto_ptr behaves like a constant pointer (T*
const p) and not like a pointer that refers to a constant (const T* p);
although the syntax looks the other way around

 auto_ptr as members:-
 By using auto_ptrs within a class you can also avoid resource leaks.
 If you use an auto_ptr as member instead of an ordinary pointer, you no
longer need a destructor because the auto_ptr object gets deleted with the
class object deletion.
 In addition, an auto_ptr helps to avoid resource leaks that are caused by
exceptions that are thrown during the initialization of an object. Note that
destructors are called only if any construction is completed. So, if an
exception occurs inside a constructor, destructors are only called for objects
that have been fully constructed. This might result in a resource leak
 Example:

176
177
 Note, however, that although you can skip the destructor, you still have to
program the copy constructor and the assignment operator. By default,
both would try to transfer ownership, which is probably not the intention.
 In addition, and as mentioned earlier, to avoid an unintended transfer of
ownership you should also use constant auto_ptrs here if the auto_ptr
should refer to the same object throughout its lifetime.
 Misusing auto_ptrs:- auto_ptrs satisfy a certain need; namely, to avoid
resource leaks when exception handling is used. Unfortunately, the exact
behavior of auto_ptrs changed in the past and no other kind of smart pointers
are provided in the C++ standard library, so people tend to misuse auto_ptrs.
Here are some hints to help you use them correctly
o auto_ptrs cannot share ownership:- An auto_ptr must not refer to an
object that is owned by another auto_ptr (or other object). Otherwise, if the
first pointer deletes the object, the other pointer suddenly refers to a
destroyed object, and any further read or write access may result in disaster.
o auto_ptrs are not provided for arrays:- An auto_ptr is not allowed to refer
to arrays. This is because an auto_ptr calls delete instead of delete [] for
the object it owns. Note that there is no equivalent class in the C++

178
 standard library that has the auto_ptr semantics for arrays. Instead, the
library provides several container classes to handle collections of data
o auto_ptrs are not "universal smart pointers”:- An auto_ptr is not
designed to solve other problems for which smart pointers might be useful.
In particular, they are not pointers for reference counting. (Pointers for
reference counting ensure that an object gets deleted only if the last of
several smart pointers that refer to that object gets destroyed.)
o auto_ptrs don't meet the requirements for container elements: - An
auto_ptr does not meet one of the most fundamental requirements for
elements of standard containers. That is, after a copy or an assignment
of an auto_ptr, source and sink are not equivalent. In fact, when an
auto_ptr is assigned or copied, the source auto_ptr gets modified because it
transfers its value rather than copying it. So you should not use an auto_ptr
as an element of a standard container. Fortunately, the design of the
language and library prevents this misuse from compiling in a standard
conforming environment.

 Const auto_ptr Consequences

An undesirable consequence of const auto_ptr idiom is that compiler can't provide a
default copy-constructor to a class that has a const auto_ptr member in it. This is
because the compiler generated copy-constructor always takes a const RHS as a
parameter, which can't bind with a non-const move constructor of auto_ptr. The
solution is to use Virtual Constructor idiom or use boost::scoped_ptr, which
explicitly prohibits copying by denying access to assignment and copy-constructor.

Proxy classes (Surrogates)???

 A proxy is a class that provides a modified interface to another class OR provides
an interface between actual class (implementation) and client.
 By providing clients with a proxy/wrapper class of the original class, the original
class can be totally hidden from the clients.
 For Example to hide the implementation details, proxy class can be used to support
m[i][j[] syntax for the matrix class
(proxy_matrix.cpp)

179
180
 Call m[1][2] is actually converted to m.operator[](1).operator[](2);
 Why shouldn’t my Matrix class’s interface look like an array-of-array?
Some people build a Matrix class that has an operator[] that returns a reference to
an Array object (Proxy Class Object)(or perhaps to a raw array, shudder), and that
Array object has an operator[] that returns an element of the Matrix (e.g., a
reference to a double). Thus they access elements of the matrix using syntax like
m[i][j] rather than syntax like m(i,j).
The array-of-array solution obviously works, but it is less flexible than the
operator() approach. Specifically, there are easy performance tuning tricks that can
be done with the operator() approach that are more difficult in the [][] approach,
and therefore the [][] approach is more likely to lead to bad performance, at least in
some cases.
For example, the easiest way to implement the [][] approach is to use a physical
layout of the matrix as a dense matrix that is stored in row-major form (or is it
column-major; I can't ever remember). In contrast, the operator() approach totally
hides the physical layout of the matrix, and that can lead to better performance in
some cases.
Put it this way: the operator() approach is never worse than, and sometimes better
than, the [][] approach.
The operator() approach is never worse because it is easy to implement the dense,
row-major physical layout using the operator() approach, so when that
configuration happens to be the optimal layout from a performance standpoint, the
operator() approach is just as easy as the [][] approach (perhaps the operator()
approach is a tiny bit easier, but I won't quibble over minor nits).
The operator() approach is sometimes better because whenever the optimal layout
for a given application happens to be something other than dense, row-major, the
implementation is often significantly easier using the operator() approach compared
to the [][] approach.
As an example of when a physical layout makes a significant difference, a recent
project happened to access the matrix elements in columns (that is, the algorithm
accesses all the elements in one column, then the elements in another, etc.), and if
the physical layout is row-major, the accesses can "stride the cache". For example,
if the rows happen to be almost as big as the processor's cache size, the machine can
end up with a "cache miss" for almost every element access. In this particular
project, we got a 20% improvement in performance by changing the mapping from
the logical layout (row, column) to the physical layout (column, row).
Of course there are many examples of this sort of thing from numerical methods,
and sparse matrices are a whole other dimension on this issue. Since it is, in
general, easier to implement a sparse matrix or swap row/column ordering using the
operator() approach, the operator() approach loses nothing and may gain something
— it has no down-side and a potential up-side.

Reference counting???

181
Software Engineering with Inheritance
 A derived class does not need to access the source code of the base class, but only
need the base class's object code. Therefore, independent software vendors (ISV)
can develop their own class libraries and provide clients with only object codes.
 Modifications to a base class do not require derived classes to change, as long as the
public and protected interfaces of the base class remain unchanged. Derived classes
may, however, need to be recompiled.
 Although in theory users do not have to know the source code of the inherited class,
in practice lots of programmers still seem reluctant to use something that they don't
know. On the other hand, when performance is a major concern, programmers may
want to see source code of classes they are inheriting from, so that they can tune the
code to meet their performance requirements.
 A base class specifies commonality -- all classes derived from a base class inherit
the capabilities and interfaces of that base class. In the object oriented design
process, the designer looks for commonality and "factors it out" to form a base
class. Derived classes are then customized upon the base class.
 In a object oriented system, classes are often closely related. So the best way is to
"factor out" common attributes and behaviors and place them in a base class, then
use inheritance to form derived classes

Finally Some Important points

 Always create class hierarchy.
 Avoid breaking of client code when server adds new types
 Avoid selection (if else statements) on the client side.
 Client will always address the base class.
 Invoke functions using base class pointer/ reference
 Based on the object at runtime, corresponding
 Function will be invoked.
 Polymorphism (same interface; different implementations)

182
Preprocessor

Preprocessor macros (#define, #undef)

 To define preprocessor macros we can use #define. Its syntax is:

#define identifier replacement

When the preprocessor encounters this directive, it replaces any occurrence

of identifier in the rest of the code by replacement. This replacement can be an
expression, a statement, a block or simply anything. The preprocessor does not
understand C++ proper, it simply replaces any occurrence
of identifier by replacement.

Function macros

 #define can work also with parameters to define function macros:

#define getmax(a,b) a>b?a:b

This would replace any occurrence of getmax followed by two arguments by the
replacement expression, but also replacing each argument by its identifier, exactly
as you would expect if it was a function:

 Defined macros are not affected by block structure. A macro lasts until it is
undefined with the #undef preprocessor directive:

#define TABLE_SIZE 100

int table1[TABLE_SIZE];
#undef TABLE_SIZE
#define TABLE_SIZE 200
int table2[TABLE_SIZE];
 Function macro definitions accept two special operators (# and ##) in the
replacement sequence:
If the operator # is used before a parameter is used in the replacement sequence,
that parameter is replaced by a string literal (as if it were enclosed between double
quotes)

#define str(x) #x
cout << str(test);

This would be translated into:

cout << "test";

183
 The operator ## concatenates two arguments leaving no blank spaces between
them:

#define glue(a,b) a ## b
glue(c,out) << "test";

This would also be translated into:

cout << "test";

Because preprocessor replacements happen before any C++ syntax check, macro
definitions can be a tricky feature. But, be careful: code that relies heavily on
complicated macros become less readable, since the syntax expected is on many
occasions different from the normal expressions programmers expect in C++.

Conditional inclusions (#ifdef, #ifndef, #if, #endif, #else and #elif)

 These directives allow to include or discard part of the code of a program if a

certain condition is met.
 #ifdef allows a section of a program to be compiled only if the macro that is
specified as the parameter has been defined, no matter which its value is.
For example:
#if TABLE_SIZE>200
#undef TABLE_SIZE
#define TABLE_SIZE 200

#elif TABLE_SIZE<50
#undef TABLE_SIZE
#define TABLE_SIZE 50

#else
#undef TABLE_SIZE
#define TABLE_SIZE 100
#endif

int table[TABLE_SIZE];

 The behavior of #ifdef and #ifndef can also be achieved by using the special
operators defined and !defined respectively in any #if or #elif directive:

#if defined ARRAY_SIZE

#define TABLE_SIZE ARRAY_SIZE
#elif !defined BUFFER_SIZE
#define TABLE_SIZE 128
#else
#define TABLE_SIZE BUFFER_SIZE
#endif

184
 Conditional Compilation

 Conditional compilation is commonly used as a debugging aid

i. #define DEBUG 1
ii. Then enclose all debugging codes in
#if DEBUG
#endif
iii. Then after debugging is finished you only need to change “1” to “0” to disable
all debugging codes.
iv. The #define preprocessor directive creates a file-scope symbolic constant. When
preprocessor sees
#define <constant>
v. It will create a constant named "CONSTANT" in the scope of this file. Then
"defined CONSTANT" will return true. Therefore, you can use the following
predirectives to wrap some code
#ifndef _ANY_SYMBOL
#define _ANY_SYMBOL
...
#endif

vi. To undefine it, say

#undef <constant>

Line Control (#line)

 When we compile a program and some error happens during the compiling process,
the compiler shows an error message with references to the name of the file where
the error happened and a line number, so it is easier to find the code generating the
error.
 The #line directive allows us to control both things, the line numbers within the
code files as well as the file name that we want that appears when an error takes
place. Its format is:

#line number "filename"

Where number is the new line number that will be assigned to the next code line.
The line numbers of successive lines will be increased one by one from this point
on.
"filename" is an optional parameter that allows to redefine the file name that will be
shown. For example:

#line 20 "assigning variable"

int a?;

This code will generate an error that will be shown as error in file "assigning
variable", line 20.

Error directive (#error)

185
This directive aborts the compilation process when it is found, generating a compilation
error that can be specified as its parameter:

#ifndef __cplusplus
#error A C++ compiler is required!
#endif

This example aborts the compilation process if the macro name __cplusplus is not
defined (this macro name is defined by default in all C++ compilers).

Source file inclusion (#include)***

 The #include preprocessor directive causes a copy of a specific file to be pasted in

place of the directive before compilation.
 It is used when another file contains the type definition that you want to use.
 For global variables and functions contained in another file, you do not include that
file. Instead you inform the compiler with the extern keyword before you use it that
it is a global variable or function and the compiler should find it out itself:
extern ULONG m_refCount; // global variable
extern void Lock(BOOL fLock); // global function
 There are two forms of the #include directive:
#include <filename>
#include “filename”
File included in “< >” will be searched in the system’s pre-defined locations, while
the file included by quotes will be first searched in the current directory, then the
pre-defined locations.

 Self containment***
If header file A makes use of a type defined in file B, normally it should include B
before using that type. Such a file can be called “self-contained”. Not all files are
“self-contained”. Some library header files are very comprehensive and contains
lots of type definitions. Different definitions may use other definitions defined in
other files. If we want such files to be self contained, we may virtually end up with
each header file including all other header files. Considering that most clients
include such a header file just to use one or two definitions in it, it will be a big
waste of space. Therefore, such a header may decide not to include some other
files. If you want to include use type A defined in file X, and type A uses type B
which is defined in file Y, it is your duty to insure that file Y is included in front of
file X:
Example:

186
Pragma directive (#pragma)

This directive is used to specify diverse options to the compiler. These options are
specific for the platform and the compiler you use. Consult the manual or the reference
of your compiler for more information on the possible parameters that you can define
with #pragma.
If the compiler does not support a specific argument for #pragma, it is ignored - no
syntax error is generated.

Predefined macro names

187
The following macro names are always defined (they all begin and end with two
underscore characters, _):

macro value
Integer value representing the current line in the source code file being
__LINE__
compiled.
A string literal containing the presumed name of the source file being
__FILE__
compiled.
A string literal in the form "Mmm dd yyyy" containing the date in
__DATE__
which the compilation process began.
A string literal in the form "hh:mm:ss" containing the time at which the
__TIME__
compilation process began.
An integer value. All C++ compilers have this constant defined to some
value. Its value depends on the version of the standard supported by the
compiler:
 199711L: ISO C++ 1998/2003
__cplusplus  201103L: ISO C++ 2011

Non conforming compilers define this constant as some value at most

five digits long. Note that many compilers are not fully conforming and
thus will have this constant defined as neither of the values above.
1 if the implementation is a hosted implementation (with all standard
__STD_HOSTED__ headers available)
0 otherwise.

The following macros are optionally defined, generally depending on whether a feature
is available:

macro value
In C: if defined to 1, the implementation conforms
__STDC__ to the C standard.
In C++: Implementation defined.
In C:
 199401L: ISO C 1990, Ammendment 1
 199901L: ISO C 1999
__STDC_VERSION__
 201112L: ISO C 2011

In C++: Implementation defined.

1 if multibyte encoding might give a character a
__STDC_MB_MIGHT_NEQ_WC__
different value in character literals
A value in the form yyyymmL, specifying the date
__STDC_ISO_10646__ of the Unicode standard followed by the encoding
of wchar_t characters
__STDCPP_STRICT_POINTER_SAFE 1 if the implementation has strict pointer
TY__ safety (see get_pointer_safety)

188
__STDCPP_THREADS__ 1 if the program can have more than one thread
Example
//standard macro names
#include <iostream>
using namespace std;

int main()
{
cout << "This is the line number " << __LINE__;
cout << " of file " << __FILE__ << ".\n";
cout << "Its compilation began " << __DATE__;
cout << " at " << __TIME__ << ".\n";
cout << "The compiler gives a __cplusplus value of " << __cplusplus;
return 0;
}

Why are preprocessor macros evil

There are a few aspects to macros that make them "bad"

1. You can't debug macros.
2. Macro expansion can lead to strange side effects.
3. Macros have no "namespace", so if you have a macro that clashes with a name used
elsewhere, you get macro replacements where you didn't want it, and this usually
leads to strange error messages.
4. Macros may affect things you don't realise.

Preprocessor pitfalls***

???

Inline functions

To avoid the calling overhead of small functionality, the compiler can be instructed to
make them inline so that compiler can replace those function definition wherever those
are being called. This can be done by placing the keyword ‘inline’ while defining the
function.
Pros:-
 It speeds up your program by avoiding function calling overhead.
 It save overhead of variables push/pop on the stack, when function calling happens.
 It save overhead of return call from a function.
 It increases locality of reference by utilizing instruction cache.
 By marking it as inline, you can put a function definition in a header file (i.e. it can
be included in multiple compilation unit, without the linker complaining)
Cons:-
 It increases the executable size due to code expansion.

189
  C++ inlining is resolved at compile time. Which means if you change the code of
the inlined function, you would need to recompile all the code using it to make sure
it will be updated
 When used in a header, it makes your header file larger with information which
users don’t care.
 As mentioned above it increases the executable size, which may cause thrashing in
memory. More number of page fault bringing down your program performance.
 Sometimes not useful for example in embedded system where large executable size
is not preferred at all due to memory constraints.

Macro Vs inline functions

 Macros
 Macros are C-style
 No spaces between name of macro and brace.
 Generic.
 Macros have side effects.
 It has two advantages: it can be applied to different types and it saves a method
call.
 Its disadvantage is that there is no type checking.
 A macro has no concept of the scoping i.e. to. there is simply no way to express
class scope in a macro

 Inline functions
 Likely efficient
 bloating of code
 request to inline the code at the point of call
 type safe: The compiler will check for the proper use of the function argument
list and return value (performing any necessary conversions), something the
preprocessor is incapable of
 no side effects
 inline fn works same as the out of line fn
 internal linkage
 fn should be defined in the same translation
 code exposed
 It can be implemented as templates in C++ which has all the benefits of macros
and meanwhile performs type checking
 You’ll almost always want to put inline definitions in a header file. When the
compiler sees such a definition, it puts the function type (the signature
combined with the return value) and the function body in its symbol table.
An inline function in a header file has a special status, since you must include
the header file containing the function and its definition in every file where the
function is used, but you don’t end up with multiple definition errors (however,
the definition must be identical in all places where the inline function is
included).

190
  When inlining is effective the compiler holds the function type (that is, the
function prototype including the name and argument types, in combination with
the function return value) in its symbol table.
When the compiler sees that the inline’s function type and the function body
parses without error, the code for the function body is also brought into the
symbol table.


The C assert( ) macro

 In the standard header file <cassert>you’ll find assert( ), which is a convenient

debugging macro. When you use assert( ), you give it an argument that is an expression
you are “asserting to be true.”
 The preprocessor generates code that will test the assertion. If the assertion isn’t true,
the program will stop after issuing an error message telling you what the assertion was
and that it failed.

191
192
Nice C++ FAQs

Why doesn't overloading work for derived classes?

That question (in many variations) are usually prompted by an example like this
#include<iostream>
using namespace std;

class B {
public:
int f(int i) { cout << "f(int): "; return i+1; }
// ...
};
class D : public B {
public:
double f(double d) { cout << "f(double): "; return d+1.3; }
// ...
};

int main()
{
D* pd = new D;
cout << pd->f(2) << '\n';
cout << pd->f(2.3) << '\n';
}

which will produce:

f(double): 3.3
f(double): 3.6
rather than the
f(int): 3
f(double): 3.6
that some people (wrongly) guessed.

In other words, there is no overload resolution between D and B. The compiler looks
into the scope of D, finds the single function "double f(double)" and calls it. It never
bothers with the (enclosing) scope of B. In C++, there is no overloading across scopes -
derived class scopes are not an exception to this general rule. (See D&E or TC++PL3
for details).

But what if I want to create an overload set of all my f() functions from my base and
derived class? That's easily done using a using-declaration:

class D : public B {
public:
using B::f; // make every f from B available
double f(double d) { cout << "f(double): "; return d+1.3; }
// ...

193
};

Give that modification, the output will be

f(int): 3
f(double): 3.6
That is, overload resolution was applied to B's f() and D's f() to select the most
appropriate f() to call.

Is there a "placement delete"?

No, but if you need one you can write your own.
Consider placement new used to place objects in a set of arenas

class Arena {
public:
void* allocate(size_t);
void deallocate(void*);
// ...
};

void* operator new(size_t sz, Arena& a)

{
return a.allocate(sz);
}

Arena a1(some arguments);

Arena a2(some arguments);

Given that, we can write

X* p1 = new(a1) X;
Y* p2 = new(a1) Y;
Z* p3 = new(a2) Z;
// ...

But how can we later delete those objects correctly? The reason that there is no built-in
"placement delete" to match placement new is that there is no general way of assuring
that it would be used correctly. Nothing in the C++ type system allows us to deduce that
p1 points to an object allocated in Arena a1. A pointer to any X allocated anywhere can
be assigned to p1.
However, sometimes the programmer does know, and there is a way:

template<class T> void destroy(T* p, Arena& a)

{
if (p) {
p->~T(); // explicit destructor call
a.deallocate(p);
}
}

194
Now, we can write:
destroy(p1,a1);
destroy(p2,a2);
destroy(p3,a3);

If an Arena keeps track of what objects it holds, you can even write destroy() to defend
itself against mistakes.
It is also possible to define a matching operator new() and operator delete() pairs for a
class hierarchy

Why can't I define constraints for my template parameters?

Well, you can, and it's quite easy and general.

Consider:
template<class Container>
void draw_all(Container& c)
{
for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}
If there is a type error, it will be in the resolution of the fairly complicated for_each()
call. For example, if the element type of the container is an int, then we get some kind
of obscure error related to the for_each() call (because we can't invoke Shape::draw()
for an int).
To catch such errors early, I can write:

template<class Container>
void draw_all(Container& c)
{
Shape* p = c.front(); // accept only containers of Shape*s

for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

The initialization of the spurious variable "p" will trigger a comprehensible error
message from most current compilers. Tricks like this are common in all languages and
have to be developed for all novel constructs. In production code, I'd probably write
something like:
template<class Container>
void draw_all(Container& c)
{
typedef typename Container::value_type T;
Can_copy<T,Shape*>(); // accept containers of only Shape*s

for_each(c.begin(),c.end(),mem_fun(&Shape::draw));
}

195
This makes it clear that I'm making an assertion. The Can_copy template can be defined
like this:
template<class T1, class T2> struct Can_copy
{
static void constraints(T1 a, T2 b) { T2 c = a; b = a; }
Can_copy() { void(*p)(T1,T2) = constraints; }
};
Can_copy checks (at compile time) that a T1 can be assigned to a T2.
Can_copy<T,Shape*> checks that T is a Shape* or a pointer to a class publicly derived
from Shape or a type with a user-defined conversion to Shape*. Note that the definition
is close to minimal:
one line to name the constraints to be checked and the types for which to check them
one line to list the specific constraints checked (the constraints() function)
one line to provide a way to trigger the check (the constructor)
Note also that the definition has the desirable properties that
You can express constraints without declaring or copying variables, thus the writer of a
constraint doesn't have to make assumptions about how a type is initialized, whether
objects can be copied, destroyed, etc. (unless, of course, those are the properties being
tested by the constraint)
No code is generated for a constraint using current compilers
No macros are needed to define or use constraints
Current compilers give acceptable error messages for a failed constraint, including the
word "constraints" (to give the reader a clue), the name of the constraints, and the
specific error that caused the failure (e.g. "cannot initialize Shape* by double*")
So why is something like Can_copy() - or something even more elegant - not in the
language? D&E contains an analysis of the difficulties involved in expressing general
constraints for C++. Since then, many ideas have emerged for making these constraints
classes easier to write and still trigger good error messages. For example, I believe the
use of a pointer to function the way I do in Can_copy originates with Alex Stepanov
and Jeremy Siek. I don't think that Can_copy() is quite ready for standardization - it
needs more use. Also, different forms of constraints are in use in the C++ community;
there is not yet a consensus on exactly what form of constraints templates is the most
effective over a wide range of uses.
However, the idea is very general, more general than language facilities that have been
proposed and provided specifically for constraints checking. After all, when we write a
template we have the full expressive power of C++ available. Consider:
template<class T, class B> struct Derived_from {
static void constraints(T* p) { B* pb = p; }
Derived_from() { void(*p)(T*) = constraints; }
};

template<class T1, class T2> struct Can_copy {

static void constraints(T1 a, T2 b) { T2 c = a; b = a; }
Can_copy() { void(*p)(T1,T2) = constraints; }
};

template<class T1, class T2 = T1> struct Can_compare {

static void constraints(T1 a, T2 b) { a==b; a!=b; a<b; }

196
 Can_compare() { void(*p)(T1,T2) = constraints; }
};

template<class T1, class T2, class T3 = T1> struct Can_multiply {

static void constraints(T1 a, T2 b, T3 c) { c = a*b; }
Can_multiply() { void(*p)(T1,T2,T3) = constraints; }
};

struct B { };
struct D : B { };
struct DD : D { };
struct X { };

int main()
{
Derived_from<D,B>();
Derived_from<DD,B>();
Derived_from<X,B>();
Derived_from<int,B>();
Derived_from<X,int>();

Can_compare<int,float>();
Can_compare<X,B>();
Can_multiply<int,float>();
Can_multiply<int,float,double>();
Can_multiply<B,X>();

Can_copy<D*,B*>();
Can_copy<D,B*>();
Can_copy<int,B*>();
}

// the classical "elements must derived from Mybase*" constraint:

template<class T> class Container : Derived_from<T,Mybase> {

// ...
};
Actually, Derived_from doesn't check derivation, but conversion, but that's often a
better constraint. Finding good names for constraints can be hard.

Why can't I assign a vector<Apple*> to a vector<Fruit*>?

Because that would open a hole in the type system
For example:
class Apple : public Fruit { void apple_fct(); /* ... */ };
class Orange : public Fruit { /* ... */ }; // Orange doesn't have apple_fct()

vector<Apple*> v; // vector of Apples

197
void f(vector<Fruit*>& vf) // innocent Fruit manipulating function
{
vf.push_back(new Orange); // add orange to vector of fruit
}

void h()
{
f(v); // error: cannot pass a vector<Apple*> as a vector<Fruit*>
for (int i=0; i<v.size(); ++i) v[i]->apple_fct();
}
Had the call f(v) been legal, we would have had an Orange pretending to be an Apple.
An alternative language design decision would have been to allow the unsafe
conversion, but rely on dynamic checking. That would have required a run-time check
for each access to v's members, and h() would have had to throw an exception upon
encountering the last element of v.

How do I read a string from input?

You can read a single, whitespace terminated word like this:
#include<iostream>
#include<string>
using namespace std;

int main()
{
cout << "Please enter a word:\n";
string s;
cin>>s;
cout << "You entered " << s << '\n';
}
Note that there is no explicit memory management and no fixed-sized buffer that you
could possibly overflow.
If you really need a whole line (and not just a single word) you can do this:
#include<iostream>
#include<string>
using namespace std;

int main()
{
cout << "Please enter a line:\n";
string s;
getline(cin,s);
cout << "You entered " << s << '\n';
}

Why can't I overload dot, ::, sizeof, etc.?

Most operators can be overloaded by a programmer. The exceptions are
198
 . (dot) :: ?: sizeof
There is no fundamental reason to disallow overloading of ?:. I just didn't see the
need to introduce the special case of overloading a ternary operator. Note that a
function overloading expr1?expr2:expr3 would not be able to guarantee that only one
of expr2 and expr3 was executed.
Sizeof cannot be overloaded because built-in operations, such as incrementing a
pointer into an array implicitly depends on it. Consider:
X a[10];
X* p = &a[3];
X* q = &a[3];
p++; // p points to a[4]
// thus the integer value of p must be
// sizeof(X) larger than the integer value of q
Thus, sizeof(X) could not be given a new and different meaning by the programmer
without violating basic language rules.
In N::m neither N nor m are expressions with values; N and m are names known
to the compiler and :: performs a (compile time) scope resolution rather than an
expression evaluation. One could imagine allowing overloading of x::y where x is an
object rather than a namespace or a class, but that would - contrary to first appearances
- involve introducing new syntax (to allow expr::expr). It is not obvious what benefits
such a complication would bring.
Operator . (dot) could in principle be overloaded using the same technique as used
for ->. However, doing so can lead to questions about whether an operation is meant
for the object overloading . or an object referred to by . For example:
class Y {
public:
void f();
// ...
};

class X { // assume that you can overload .

Y* p;
Y& operator.() { return *p; }
void f();
// ...
};

void g(X& x)
{
x.f(); // X::f or Y::f or error?
}
This problem can be solved in several ways. At the time of standardization, it was not
obvious which way would be best.

How do I convert an integer to a string?

The simplest way is to use a stringstream:

199
#include<iostream>
#include<string>
#include<sstream>
using namespace std;

string itos(int i) // convert int to string

{
stringstream s;
s << i;
return s.str();
}

int main()
{
int i = 127;
string ss = itos(i);
const char* p = ss.c_str();
cout << ss << " " << p << "\n";
}
Naturally, this technique works for converting any type that you can output using << to
a string.

How do I call a C function from C++?

Just declare the C function ``extern "C"'' (in your C++ code) and call it (from your C or
C++ code). For example:
// C++ code
extern "C" void f(int); // one way

extern "C" { // another way

int g(double);
double h();
};

void code(int i, double d)

{
f(i);
int ii = g(d);
double dd = h();
// ...
}
The definitions of the functions may look like this:
/* C code: */

void f(int i)
{
/* ... */
}

200
int g(double d)
{
/* ... */
}

double h()
{
/* ... */
}

Note that C++ type rules, not C rules, are used. So you can't call function declared
``extern "C"'' with the wrong number of argument. For example:
// C++ code

void more_code(int i, double d)

{
double dd = h(i,d); // error: unexpected arguments
// ...
}

Should I put "const" before or after the type?

I put it before, but that's a matter of taste. "const T" and "T const" were - and are -
(both) allowed and equivalent. For example:
const int a = 1;// ok
int const b = 2; // also ok

What good is static_cast?

Casts are generally best avoided. With the exception of dynamic_cast, their use implies
the possibility of a type error or the truncation of a numeric value. Even an innocent-
looking cast can become a serious problem if, during development or maintenance, one
of the types involved is changed. For example, what does this mean?:
x = (T)y;
We don't know. It depends on the type T and the types of x and y. T could be the name
of a class, a typedef, or maybe a template parameter. Maybe x and y are scalar variables
and (T) represents a value conversion. Maybe x is of a class derived from y's class and
(T) is a downcast. Maybe x and y are unrelated pointer types. Because the C-style cast
(T) can be used to express many logically different operations, the compiler has only
the barest chance to catch misuses.
The "new-style casts" were introduced to give programmers a chance to state their
intentions more clearly and for the compiler to catch more errors. For example:
int a = 7;
double* p1 = (double*) &a; // ok (but a is not a double)
double* p2 = static_cast<double*>(&a); // error
double* p2 = reinterpret_cast<double*>(&a); // ok: I really mean it

const int c = 7;
201
 int* q1 = &c; // error
int* q2 = (int*)&c; // ok (but *q2=2; is still invalid code and may fail)
int* q3 = static_cast<int*>(&c); // error: static_cast doesn't cast away const
int* q4 = const_cast<int*>(&c); // I really mean it

The idea is that conversions allowed by static_cast are somewhat less likely to lead to
errors than those that require reinterpret_cast. In principle, it is possible to use the result
of a static_cast without casting it back to its original type, whereas you should always
cast the result of a reinterpret_cast back to its original type before using it to ensure
portability.

So, what's wrong with using macros?

Macros do not obey the C++ scope and type rules. This is often the cause of subtle and
not-so-subtle problems. Consequently, C++ provides alternatives that fit better with the
rest of C++, such as inline functions, templates, and namespaces.
Consider:
#include "someheader.h"
struct S {
int alpha;
int beta;
};
If someone (unwisely) has written a macro called "alpha" or a macro called "beta" this
may not compile or (worse) compile into something unexpected. For example,
"someheader.h" may contain:
#define alpha 'a'
#define beta b[2]
Conventions such as having macros (and only macros) in ALLCAPS helps, but there is
no language-level protection against macros. For example, the fact that the member
names were in the scope of the struct didn't help: Macros operate on a program as a
stream of characters before the compiler proper sees it. This, incidentally, is a major
reason for C and C++ program development environments and tools have been
unsophisticated: the human and the compiler see different things.
Unfortunately, you cannot assume that other programmers consistently avoid what you
consider "really stupid". For example, someone recently reported to me that they had
encountered a macro containing a goto. I have seen that also and heard arguments that
might - in a weak moment - appear to make sense. For example:

#define prefix get_ready(); int ret__

#define Return(i) ret__=i; do_something(); goto exit
#define suffix exit: cleanup(); return ret__

void f()
{
prefix;
// ...
Return(10);
// ...

202
 Return(x++);
//...
suffix;
}
Imagine being presented with that as a maintenance programmer; "hiding" the macros
in a header - as is not uncommon - makes this kind of "magic" harder to spot.
One of the most common subtle problems is that a function-style macro doesn't obey
the rules of function argument passing. For example:

#define square(x) (x*x)

void f(double d, int i)
{
square(d); // fine
square(i++); // ouch: means (i++*i++)
square(d+1); // ouch: means (d+1*d+1); that is, (d+d+1)
// ...
}
The "d+1" problem is solved by adding parentheses in the "call" or in the macro
definition:

#define square(x) ((x)*(x)) /* better */

However, the problem with the (presumably unintended) double evaluation of i++
remains.
And yes, I do know that there are things known as macros that doesn't suffer the
problems of C/C++ preprocessor macros. However, I have no ambitions for improving
C++ macros. Instead, I recommend the use of facilities from the C++ language proper,
such as inline functions, templates, constructors (for initialization), destructors (for
cleanup), exceptions (for exiting contexts), etc.

Is there is any reason to make the permissions on an overridden C++ virtual function
different from the base class? Is there any danger in doing so?
For example:
class base {
public:
virtual int foo(double) = 0;
}

class child : public base {

private:
virtual int foo(double);
}
The C++ faq says that it is a bad idea, but doesn't say why.
My concrete questions:
1. Is there any technical problem with using a different permission for virtual
methods in derived classes vs base class?
2. Is there any legitimate reason to do so?

203
Ans:

The problem is that the Base class methods are its way of declaring its interface. It is, in
essence saying, "These are the things you can do to objects of this class."
When in a Derived class you make something the Base had declared as public private,
you are taking something away. Now, even though a Derived object "is-a" Base object,
something that you should be able to do to a Base class object you cannot do to a
Derived class object, breaking the Liskov Substitution Prinicple
Will this cause a "technical" problem in your program? Maybe not. But it will probably
mean object of your classes won't behave in a way your users expect them to behave.

Ans:
You do get the surprising result that if you have a child, you can't call foo, but you can
cast it to a base and then call foo.
child *c = new child();
c->foo; // compile error (can't access private member)
static_cast<base *>(c)->foo(); // this is fine, but still calls the implementation in
child

Ans:
There's no technical problem, but you will end up with a situation where the publicly
available functions will depend upon whether you have a base or derived pointer.
This in my opinion would be weird and confusing.

Ans:
It can be very useful if you are using private inheritance - i.e. you want to reuse a
(customized) functionality of a base class, but not the interface.

Ans:
1. No technical problem, if you mean by technical as there being a hidden runtime
cost.
2. If you inherit base publically, you shouldn't do this. If you inherit via protected
or private, then this can help prevent using methods that don't make sense unless
you have a base pointer.

What happens when you make call "delete this?

The code has two built-in pitfalls. First, if it executes in a member function for an
extern, static, or automatic object, the program will probably crash as soon as the delete
statement executes. There is no portable way for an object to tell that it was instantiated
on the heap, so the class cannot assert that its object is properly instantiated. Second,
when an object commits suicide this way, the using program might not know about its
demise. As far as the instantiating program is concerned, the object remains in scope
and continues to exist even though the object did itself in. Subsequent dereferencing of
the pointer can and usually does lead to disaster.

204
You should never do this. Since compiler does not know whether the object was
allocated on the stack or on the heap, "delete this" could cause a disaster.

How virtual functions are implemented C++?

Virtual functions are implemented using a table of function pointers, called the vtable.
There is one entry in the table per virtual function in the class. This table is created by
the constructor of the class. When a derived class is constructed, its base class is
constructed first which creates the vtable. If the derived class overrides any of the base
classes virtual functions, those entries in the vtable are overwritten by the derived class
constructor. This is why you should never call virtual functions from a constructor:
because the vtable entries for the object may not have been set up by the derived class
constructor yet, so you might end up calling base class implementations of those virtual
functions

Can you think of a situation where your program would crash without reaching the
breakpoint which you set at the beginning of main()?

C++ allows for dynamic initialization of global variables before main() is invoked. It is
possible that initialization of global will invoke some function. If this function crashes
the crash will occur before main() is entered.

What does extern "C" int func(int *, Foo) accomplish?

It will turn off "name mangling" for func so that one can link to code compiled by a C
compiler.

What are storage qualifiers in C++?

They are

 const
 volatile
 mutable

const keyword indicates that memory once initialized, should not be altered by a
program.

volatile keyword indicates that the value in the memory location can be altered even
though nothing in the program code modifies the contents. For example if you have a
pointer to hardware location that contains the time, where hardware changes the value
of this pointer variable and not the program. The intent of this keyword to improve the
optimization ability of the compiler.

mutable keyword indicates that particular member of a structure or class can be altered
even if a particular structure variable, class, or class member function is constant.

205
struct data
{
char name[80];
mutable double salary;
}

const data MyStruct = { "Satish Shetty", 1000 }; //initlized by complier

strcpy ( MyStruct.name, "Shilpa Shetty"); // compiler error

MyStruct.salaray = 2000 ; // complier is happy allowed

206
MORE NICE C++ FAQs (from C++ FAQs Book - MARSHALL CLINE)

???

207
Brainbench like Questions

extern

 An extern declaration does not define the variable unless it is also initialized in
the same statement

Declaration

 In the below code snippet the local x in main hides the global x before the local x's
initializer is considered. Therefore the local x is being initialized with itself (the
local unitialized variable)

int x = 5;
int main(int argc, char** argv)
{
int x = x;
return 0;
}

 In the below code snippet the local x does not hide the global x until the end of the
declaration. A local name will hide a global after the end of the declaration but
before the beginning of initialization.
const int x = 5;
int main(int argc, char** argv)
{
int x[x];
int y = sizeof(x) / sizeof(int);
return 0;
}
 You can have a class and a regular variable with the same name. However the class
name will be hidden and the elaborated-type-specifier must be used to access the
class name.
So the below code snippet is legal

int x = 5;
class x
{
};

int main(int argc, char** argv)

{
class x y;

return 0;
208
 }

 A template class name can’t be the same as any other name in the same declarative
region. This is also the case for typedef names.
So the below code snippet is not legal
int x = 5;

template <typename T>

class x
{
T member;
};

int main(int argc, char** argv)

{
class x<int> y;

return 0;
}

Scope Exception

 Function parameters are accessible in the try handler. Function local variables are
NOT accessible in the try handler.
So the variable x and e will be available in try block.
void foo(int x) try
{
int y = 2;
throw 1;
}
catch(int e)
{
}

int main(int argc, char** argv)

{
foo(3);
return 0;
}

Scope-if

 The variable declared in the else-if did not exist before its declaration and can not
be used after the end of the else clause. Variables declared in conditions of if,else-
if,else structures can be used in all subsequent conditions and bodies of the if,else-
if,else structure.
So in the below code snippet the variable y will be accessible in lines 8-15 only.
1 int main(int argc, char** argv)
209
 2 {
3
4 if ( argc > 10 )
5 {
6
7 }
8 else if (int y = argc - 1 )
9 {
10
11 }
12 else
13 {
14
15 }
16
17 return 0;
18 }

Class scope

 If reordering member declarations in a class yields an alternate valid program the

program is ill-formed. In the code snippet below, the enum SIZE is not in scope
when array is declared making the array size 5. However if the members were
reordered to declare array after the definition of the enum the array size would be 3.
Thus since reordering member declaration changes the program, it is undefined.
#include <iostream>

const int SIZE = 5;

struct tester
{
int array[SIZE];

enum
{
SIZE = 3
};

void size()
{
std::cout << sizeof(array) / sizeof(int);
}
};

int main(int argc, char** argv)

{
tester t;

210
 t.size();
return 0;
}

 Names defined at any point in a class are in scope in all member functions of the
class. Thus, in the below code snippet, the enum SIZE is in scope in the function
foo and hides the global variable SIZE. So the value printed will be 3.
#include <iostream>

const int SIZE = 5;

struct tester
{
void foo()
{
std::cout << SIZE << std::endl;
}

enum
{
SIZE = 3
};
};

int main(int argc, char** argv)

{
tester t;
t.foo();
return 0;
}

enum declarations

 An Enumeration's point of declaration is after its definition (which includes the

initialization). Therefore in this case the value of the enum 'x' is initialized with the
global 'x' which equals 12
#include <iostream>

const int x = 12;

int main(int argc, char** argv)

{
enum dog
{
x = x,
y
};

211
 std::cout << y << std::endl;

return 0;
}

Namespace lookup

#include <iostream>

namespace standards
{
struct datastructure
{
};

void foo(const datastructure& ds)

{
}

void bar()
{
}
}

int main(int argc, char** argv)

{
standards::datastructure ds;

foo(ds);

bar();

return 0;
}

In the above code snippet the namespace 'standards' is searched for a function 'foo'
because its argument 'ds' is defined in that namespace. For function 'bar', no additional
namespaces are searched and the name is not found.
This is called koenig lookup or argument dependent name lookup.

Linkage

 Static const has external linkage so can be accessed from another translation unit.
So in the below code snippet variable w and z can be accessed from another
translation unit.
int w = 1;

212
 static int x = 2;
const int y = 3;
extern const int z = 4;

int main(int argc, char** argv)

{
return 0;
}

Static Storage

 Variables with static storage duration are zero initialized. Note that x has static
storage duration even though the static keyword is not used. According to the
standard: "All objects which do not have dynamic storage duration, do not have
thread storage duration, and are not local have static storage duration"
#include <iostream>

int x;

int main()
{
int y;
std::cout << x << std::endl;
std::cout << y << std::endl;
return 0;
}

Standard Conversions

 Arrays can be implicity converted to pointers without casting. There is no implicit

conversion from pointers to arrays.
int main()
{
int a[54] = {};
int b[54] = {};
int* x = a;
int* const y = a;
b = x; //1)
b = y; //2)
return 0;
}
So in the above code snippet 1) and 2) will not compile.

 int* can be implicity converted to int const* -- 4.4. There is no implicit conversion
from int const* to int*. So in the below code snippet line 9 will not compile
1 int main()
213
 2{
3 int a = 2;
4
5 int* b = &a;
6
7 int const* c = b;
8
9 b = c;
10
11 return 0;
12 }

Temporaries

 In the below code snippet int() creates a temporary variable which is an rvalue. The
temporary variable that is created can not be assigned to since it is an rvalue. Thus
this code should not compile.
#include <iostream>

int main()
{
int x = int() = 3;

std::cout << x << std::endl;

return 0;
}

Casts

 Only reinterpret_cast can be used to convert a pointer to an object to a pointer to an

unrelated object type. So in the below code snippet lines 14,15,16,18 will not
compile
1 struct Foo
2 {
3 };
4
5 struct Bar
6 {
7 };
8
9
10 int main()
11 {
12 Foo* f = new Foo;
13
214
 14 Bar* b1 = f;
15 Bar* b2 = static_cast<Bar*>(f);
16 Bar* b3 = dynamic_cast<Bar*>(f);
17 Bar* b4 = reinterpret_cast<Bar*>(f);
18 Bar* b5 = const_cast<Bar*>(f);
19
20 return 0;
21 }

 Only const_cast (or c-style casts) can be used to cast away constness
 In addition to c-style only static_cast can be used to cast an int to an enum
 In addition to c-style only reinterpret_cast can be used to cast an int to a pointer or
a pointer to an int

delete

 Deleting NULL pointers have no effect. Deleting a pointer to a base class which
points to a derived object is legal assuming the base destructor is virtual.
Deleting an array of objects using a base class pointer is undefined. (line 18 will
cause and undefined behaviour)
1 struct Foo
2{
3 virtual ~Foo() {}
4 };
5
6 struct Bar : public Foo
7{
8 };
9
10 int main(int argc, char** argv)
11 {
12 Foo* f = new Bar;
13 delete f;
14 f = 0;
15 delete f;
16
17 Foo* fa = new Bar[10];
18 delete [] fa;
19 fa = 0;
20 delete fa;
21
22 return 0;
23 }

215
Pointers comparison

 Relational operators can be used to do pointer comparison of non-static members in

the same object where the definitions of the members are not separated by an access
specifier. The member declared first will evaluate to lower.
 Other than this case, the only other time relational operators can be used to compare
pointers is when the addresses point to elements in the same array.
 For all other cases, the result of relational operators on pointers is unspecified.
struct Foo
{
int x;
int y;
};

if ( &f.x < &f.y ) //will return true

 Unary operator ++
If the first operand to the logical AND operator evaluates to false the second
operand is guaranteed not to evaluate. Note: the logical OR operator is guaranteed
not to evaluate the second operand if the first operand is true. Note: for the logical
AND and OR operators, all side effects of the first expression, except for
destruction of temporaries, happen before the second expression is evaluated.
The output of below code snippet will be 1
#include <iostream>

int main(int argc, char** argv)

{
int x = 0;
int y = 0;

if (x++ && y++)

{
y += 2;
}

std::cout << x + y << std::endl;

return 0;
}

Conditional operator

 The 2nd and 3rd operands to the conditional operator must be of the same type. If
one of the two can be converted to the other, the conversion will occur. Note: if a
conversion exists for each of the operands into the other's type, the program is ill-
formed.

216
 Any construct that could possibly be considered a declaration is a declaration. In
this example, the second line of main is interpreted as a function declaration in
preference to an object declaration with initialization.
#include <iostream>

struct Foo
{
Foo(int d) : x(d) {}
int x;
};

int main()
{
double x = 3.14;

Foo f( int(x) );

std::cout << f.x << std::endl;

return 0;
}

Array declaration

 Only the first constant expression in a multiple dimension array can be ommitted.
Therefore the declaration of the array in this example is ill-formed.
int array[3][] = {{0, 1, 2}, {3, 4, 5}, {6, 7, 8}}; //Not legal

Overloading

 There can only be one function with the same signature. Altering the cv
qualification of parameters does not change the function signature. Therefore the
two foo functions have the same signature and the program is ill-formed.
int foo(int x, int y)
{
return x+y;
}

int foo(const int x, const int y)

{
return x+y+1;
}

Default argument

217
 Parameters of a function cannot be used in default argument expressions.
int foo(int x, int y = x) //Not leagal
{
return x+y+1;
}

 Non-static members cannot be used as default arguments.

#include <iostream>

int g_x = 44;

struct Foo
{
int m_x;

static int s_x;

Foo(int x) : m_x(x) {}

int a(int x = g_x)

{
return x + 1;
}

int b(int x = m_x) //Not Legal as m_x is non-static

{
return x + 1;
}

int c(int x = s_x)

{
return x + 1;
}
};

 A virtual function call uses the default arguments in the declaration of the virtual
function determined by the static type of the pointer or reference denoting the
object. An overriding function in a derived class does not acquire default arguments
from the function it overrides.
So In the below code snippet, the method B::foo is called but with the default
argument of 5 from A::foo.
#include <iostream>

struct A
{
virtual int foo(int x = 5)
{
return x * 2;
218
 }
};

struct B : public A
{
int foo(int x = 10)
{
return x * 3;
}
};

int main(int argc, char** argv)

{
A* a = new B;

std::cout << a->foo() << std::endl;

return 0;
}

Initialization

 An aggregate is an array or a class with no user-declared constructors, no private or

protected non-static data members, no base classes, and no virtual functions."
Aggregates can be initialized by "brace-enclosed, comma separated list of
initializer-clauses for the members of the aggregate, written in increasing subscript
or member order." Static data members are skipped during this type of initialization.
If there are fewer initializers in the list than there are members in the aggregate,
then each member not explicitly initialized shall be value-initialized.
So In the below code snippet, 3.14 initializes d and not sd and i is value-
initialized to 0.
#include <iostream>

class Foo
{
public:

char c;
static double sd;
double d;
int i;
};

int main(int argc, char** argv)

{
Foo f = { 72, 3.14 };

219
 std::cout << f.c + f.d + f.i << std::endl;

return 0;
}

Virtual functions

 For virtual occurrences of a class in the Inheritance hierarchy the constructor

is called once but for each non virtual occurrence of a class the constructor is
called each time.
 So for the below code snippet the BS Constructor is called 3 times. One time for the
first virtual occurrences of BS in the hierarchy and once for each non-virtual
occurrence of BS. mid1 and mid2 together have one. mid3 and mid4 each have one.
#include <iostream>

struct BS
{
BS()
{
std::cout << "Hello World" << std::endl;
}
unsigned int color;
};

struct mid1 : virtual public BS { };

struct mid2 : virtual public BS { };
struct mid3 : public BS { };
struct mid4 : public BS { };

struct DR : public mid1, public mid2,

public mid3, public mid4 { };

int main(int argc, char** argv)

{
DR d;
return 0;
}

 Virtual inheritance affects the class that is inherited virtually.

In the below code snippet, the BS base class is not inherited virtually and there are 4
of them within 1 DR object. The virtual inheritance statements in this code are
affecting the classes mid1, mid2, mid3, mid4 and not BS. So the BS constructor
will be called 4 times.
#include <iostream>

struct BS
{
BS()
220
 {
std::cout << "Hello World" << std::endl;
}
};

struct mid1 : public BS { };

struct mid2 : public BS { };
struct mid3 : public BS { };
struct mid4 : public BS { };

struct DR : public virtual mid1, public virtual mid2, public virtual mid3, public
mid4 { };

int main(int argc, char** argv)

{
DR d;
return 0;
}

 Virtual functions must have a unique "final overrider" that overrides all other
instances of that function in its inheritance hierarchy
In the below code snippet neither Box::print nor Sphere::print override each other,
so the condition is not met and the GeoDisc class is ill-formed.
#include <iostream>

struct Shape
{
virtual void print()
{
std::cout << "SHAPE" << std::endl;
}
virtual ~Shape() {}
};

struct Box : public virtual Shape

{
void print()
{
std::cout << "BOX" << std::endl;
}
};

struct Sphere : public virtual Shape

{
void print()
{
std::cout << "SPHERE" << std::endl;
}

221
 };

struct GeoDisc : public Box, public Sphere

{
};

int main(int argc, char** argv)

{
Shape* s = new GeoDisc;

s->print();

delete s;

return 0;
}

Access Control

User defined conversions

 Conversion functions of class A convert from class A into another type

 Converting constructors must be callable with a single argument

Member Initialization

 All sub-objects representing virtual base classes are initialized by the constructor of
the most derived class. If the constructor of the most derived class does not specify
a mem-initializer for a virtual base class V, then V's default construtor is called to
initialize the virtual base class subobject.
Thus the output of below code snippet will be 20000
#include <iostream>

struct Car
{
Car() : price(20000) {}
Car(double b) : price(b*1.1) {}
double price;
};

struct Toyota : public virtual Car

{
Toyota(double b) : Car(b) {}
};

222
 struct Prius : public Toyota
{
Prius(double b) : Toyota(b) {}
};

int main(int argc, char** argv)

{
Prius p(30000);

std::cout << p.price << std::endl;

return 0;
}

Copying Objects

 It is illegal to have a constructor whose first and only non-default argument is a

value parameter for the class type.
#include <iostream>

struct A
{
A() : val() {}
A(int v) : val(v) {}
A(A a) : val(a.val) {} //Out of memory compiler error

int val;
};

int main(int argc, char** argv)

{
A a1(5);
A a2(a1);

std::cout << a1.val + a2.val << std::endl;

return 0;
}

 The below code will not compile as the third line of main tries to initialize a3 with
a2, but A's copy constructor takes a non-const reference which violates a2's const
declaration.
#include <iostream>

struct A
{
A() : val(0) {}
223
 A(int v) : val(v) {}
A(A& a) : val(a.val) {} //having a non const argument is valid for copy
constructor

int val;
};

int main(int argc, char** argv)

{
const A a1;
const A a2(5);
const A a3 = a2;

std::cout << a1.val + a2.val + a3.val << std::endl;

return 0;
}

 It is ill-formed to use an implicitly defined assignment operator when one of the

members that will need to be copied is a reference. (Line 18)
1 #include <iostream>
2
3 struct A
4{
5 A(int& var) : r(var) {}
6
7 int &r;
8 };
9
10 int main(int argc, char** argv)
11 {
12 int x = 23;
13
14 A a1(x);
15
16 A a2 = a1;
17
18 a2 = a1;
19
20 return 0;
21 }

Function Overloading

 In the below code snippet When calling global foo, the function is overloaded and
each foo is called once depending on the type of the argument. When calling the
member foo, Gateway::foo hides Computer::foo so Gateway::foo is called twice.
224
 So the output is 2 + 4 + 16 + 16 = 38
#include <iostream>

int foo(int i)
{
return 2;
}

double foo(double d)
{
return 4.0;
}

struct Computer
{
int foo(int i)
{
return 8;
}
};

struct Gateway : public Computer

{
double foo(double d)
{
return 16.0;
}
};

int main(int argc, char** argv)

{
Gateway g;

std::cout << foo(1) + foo(1.0) + g.foo(1) + g.foo(1.0) << std::endl;

return 0;
}

Member Templates

 A member function template can not be virtual so the below code snippet will
not compile
#include <iostream>

struct mybase
{
int x;

225
 template <int RANGE>
virtual void print()
{
std::cout << RANGE + x + 1 << std::endl;
}
};

struct myderived : public mybase

{
template <int RANGE>
void print()
{
std::cout << RANGE + x + 2 << std::endl;
}
};

int main(int argc, char** argv)

{
mybase* b = new myderived;

b->x = 1;

b->print<5>();

return 0;
}

Valid declaration for main

int main()
int main(int argc, char* argv[])
int main(int argc, char* argv[], char* options[])

226
Exercises

From “C++ Essentials”???

From “Thinking in C++ Volume 1”???

From “Thinking in C++ Volume 2”???

227