coders corner

With C++17 it is possible to initialize a variable inside an if-statement and a switch-statement. We already know and use this concept in the for-statement. To be honest: I don’t like this feature. Within this article I want to introduce this feature and explain my doubts. Following I will write about the if-statement only because everything also applies to the switch-statement and so it is sufficient to show one of both.

The new syntax with the initializer inside the if-statement comes with a big improvement: the variable is moved inside the scope of the if-block. An important software design concept is to use the smallest scope as possible and the new syntax helps to implement according to this design concept.

But you must pay dearly for this advantage. As the initialization moves into the if-statement, initialization and comparison will be mixed up. This violates two other software design concepts, named “separation of concerns” and “keep it simple”. Depending on the complexity of the initialization and the comparison you may create a very complex if-statement. This may result in hard to read and error prone code. Only in case you have a very simple initialization and a very simple comparison, the combination of both may stay simple as well. In all other cases I recommend avoiding the new feature and clearly separate the initialization and the comparison in order to increase the code readability.

At next i want to show some examples. Within the example a couple of functions are called. If you want to compile the example source code you could use the following implementations of These functions.

int CalcCount() { return 1000; }
int CalcExpectedCount() { return 1000; }
int CalcOldCount() { return 1000; }
bool IsInitialized() { return true; }

Let’s have a look at a simple example. The following source code shows an if-statement with an included variable initialization and the same if-statement with a separation of the initialization and the comparison. Furthermore, just for fun, I removed the line breaks for the second example to compare it with the new syntax.

Due to an issue within the wordpress codeblock element, i could not use my origin code examples. I had to remove all insertion operators „<<“ and use „..“ as placeholder. So, the examples will contain some standard outputs, and within these outputs the two points „..“ must be seen as inseration operator „<<„.

// init inside if
if (int count = CalcCount(); count > 100)
{
	std::cout .. "count: " .. count .. std::endl;  
}

// init outside if
int count = CalcCount();

if(count > 100)
{
	std::cout .. "count: " .. count .. std::endl;
}

// init outside if without line break
int count = CalcCount(); if (count > 100)
{
	std::cout .. "count: " .. count .. std::endl;
}

If we compare the first and the second implementation – so if we compare new and classical syntax – we could say that the differences are small. In my opinion both variants are easy to read. Even the third one, with classical syntax but without line breaks, may be easy to read, even if it is unusual. But you can see that the new syntax isn’t that different from the classical without line break. Just the if-statement moved at the front. Of course, this little change increased the readability a lot.

So, we must look at a more complex example. Let’s see how things look like if we increase the complexity of the initialization, but leave the comparison as simple as before.

// init inside if
if (int count = IsInitialized() ? CalcCount() : (CalcExpectedCount() + CalcOldCount()) / 2; count > 100)
{
	std::cout .. "count: " .. count .. std::endl;
}

// init outside if
int count = IsInitialized() ? CalcCount() : (CalcExpectedCount() + CalcOldCount()) / 2;

if (count > 100)
{
	std::cout .. "count: " .. count .. std::endl;
}

// init outside if, separate different init variants
int count = 0;

if (IsInitialized())
{
	count = CalcCount();
}
else
{
	count = (CalcExpectedCount() + CalcOldCount()) / 2;
}

if (count > 100)
{
	std::cout .. "count: " .. count .. std::endl;
}

At first you can see the new syntax. In my opinion this if-statement is very hard to read. You have to stop at this line of code, read it several times and look closely to understand the meaning of the code.

The second implementation separates the initialization and the comparison. I think this will make it a little bit easier to read the code.

The third example clearly separates the different concerns. We have a standard initialization, an initialization for fallback cases and a comparison. This source code is easy to read. You don’t have to stop reading at any line of code as you must read it again to understand it. The complex initialization and comparison is spitted into simple parts.

Summary

Initializers in if-statements and switch-statements allow a clear assignment of the variable to the scope of the statement. But mixing the two concerns of initialization and comparison will often result in complex code. Therefore, in my opinion, the new syntax should be used with caution. If the initialization as well as the comparison is short and simple the resulting combination of both may be simple too and in this case the new syntax should be used.

The C++ name hiding rules for variables are well known by software developers. In contrast, name hiding in inheritance sometimes leads to issues although it follows the same rules. Such issues are therefore not a result of the rules but an effect due to different expectations in these different programming scenarios.

Name hiding rules for variables

Let’s start with the well-known rules for variables. The following example shows a typical scenario.

double x;
	
int main()
{
	int x;

	x = 5.5;	// conversion from double to int

	std::cout << x << std::endl;	// prints 5

	::x = 8.8;	// changes the global x

	std::cout << x << std::endl;	// prints 5
	
	return 0;
}

Within this example you see a double variable within the global scope and an integer variable within the local scope. As they have the same names, the local variable hides the global one, even if they have different types. If we want to access the double variable we must use the global namespace explicitly.

Name hiding rules in inheritance

At next, let us try the same name hiding within an inheritance scenario.

class Base
{
public:
	void Calc(double x) { std::cout << "Base calc was called" << std::endl; }
};

class Derived : public Base
{
public:
	void Calc(int x) { std::cout << "Derived calc was called" << std::endl; }
};

int main()
{
	Derived d;

	d.Calc(3.5);	// derived is called, conversion of double to int
	d.Calc(8);		// derived is called

	return 0;
}

Within this example we have a function with a double parameter in the base class and a function with an integer parameter in the derived class. The same name hiding rules like in the example before are still used. The local function of the derived class will hide the global function of the base class even if the function parameters are different.

Some developers are surprised by this behavior as they expect that the public functions of the base class will become functions of the derived class too and a function call with respect to the function parameters types can be executed. That’s a valid and comprehensible expectation because from a software architectural point of view public inheritance represents a “is-a” relationship.

From technical point of view the different kinds of inheritance just result in different visibilities of interfaces. Therefore, name hiding should be seen with respect to this technical point of view. So, the behavior of the example application is correct.

Make hidden names visible

Of course, there are many use cases where you want to keep the hidden names visible. For example, in public inheritance scenarios you normally want to have the interface visible and it should be a rare case to keep it hidden. As expected, this behavior was respected for C++. With the “using” statement the hidden names will become visible again. The following example shows the according modification of the derived class. This time the base class method is called if we pass a double parameter.

class Base
{
public:
	void Calc(double x) { std::cout << "Base calc was called" << std::endl; }
};

class Derived : public Base
{
public:
	using Base::Calc;	// make base class function name visible in derived class

	void Calc(int x) { std::cout << "Derived calc was called" << std::endl; }
};

int main()
{
	Derived d;

	d.Calc(3.5);	// base is called
	d.Calc(8);		// derived is called

	return 0;
}

Make specific hidden name visible

Within the previous example we have seen the “using” statement to make hidden names visible. As we already learned, names are independent of data types. Therefore, if we have different functions with the same name implemented in the base class, these functions will become visible. The following source code shows an according example. Furthermore, I have changed to private inheritance to show that the concept is independent of the inheritance kind.

class Base
{
public:
	void Calc(double x) { std::cout << "Base calc double was called" << std::endl; }

	void Calc(std::string x) { std::cout << "Base calc string was called" << std::endl; }
};

class Derived : private Base
{
public:
	using Base::Calc;	// make base class function name visible in derived class

	void Calc(int x) { std::cout << "Derived calc was called" << std::endl; }
};

int main()
{
	Derived d;

	d.Calc(3.5);	// base is called
	d.Calc(8);		// derived is called

	d.Calc("abc");

	return 0;
}

Based on a technical point of view the example looks fine. But from a software architectural point of view you may argue that it is bad design if we make the private interface public in derived class. And you are totally right. But sometimes such design decisions are made for several reasons. But in this case you want to keep the design fault as small as possible and make only one or a few of the available functions public. You can do this by using forward declaration instead of the “using” declaration. The following source code shows the adapted example.

class Base
{
public:
	void Calc(double x) { std::cout << "Base calc double was called" << std::endl; }

	void Calc(std::string x) { std::cout << "Base calc string was called" << std::endl; }
};

class Derived : private Base
{
public:
	void Calc(double x) { Base::Calc(x); };

	void Calc(int x) { std::cout << "Derived calc was called" << std::endl; }
};

int main()
{
	Derived d;

	d.Calc(3.5);	// base is called
	d.Calc(8);		// derived is called

	d.Calc("abc");	// compiler error

	return 0;
}

Summary

Names in derived classes hide names of base classes. This behavior is correct from a technical point of view. But in case of public inheritance it contradicts our expectations from a software architectural point of view. But we can easily make the hidden names visible again with the “using” declaration or with forward declarations.

Whenever you write an application in C++ you will create a lot of object instances. So, this is a base development task. C++ offers several ways to initialize variables. These are not just syntactical variations for the same task. The different initialization kinds may result in different behaviors. This rich variety of initialization kinds can result in some pitfalls, wrong expectations and programming errors.

Within this article I want to show the different object instance creation methods and explain their differences. To fully understand the examples of this article you should know the different types of constructors. You can get or refresh knowledge about constructors within this article.

Example Class

Within the examples of this article, a class “MyClass” is used. As we want to focus on the object instance creation, this class does not have any functionality. But it will provide several standard constructors and assignment operators. The ctor’s and operators just contain console outputs. This will help to see which ctor or operator is called. The following source code shows “MyClass”.

#include "stdafx.h"
#include 
#include 
#include 

class MyClass
{
public:
	MyClass();		// default ctor
	~MyClass();		// dtor

	MyClass(const int size);		// parameterized ctor

	MyClass(const MyClass& obj);		// copy ctor
	MyClass& operator=(const MyClass& obj);		// copy assignment operator

	MyClass(MyClass&& obj);		// move ctor
	MyClass& operator=(MyClass&& obj);		// move assignment operator

	MyClass(const std::initializer_list& list);	//initializer_list ctor
};

MyClass::MyClass() 
{
	std::cout << "default ctor" << std::endl;
}

MyClass::~MyClass()
{
}

MyClass::MyClass(const int size) 
{
	std::cout << "parameterized ctor" << std::endl;	
}

MyClass::MyClass(const MyClass& obj) 
{
	std::cout << "copy ctor" << std::endl;
}

MyClass& MyClass::operator=(const MyClass& obj)
{
	std::cout << "copy assignment operator" << std::endl;
	return *this;
}

MyClass::MyClass(MyClass&& obj)
{
	std::cout << "move ctor" << std::endl;
}

MyClass& MyClass::operator=(MyClass&& obj)
{
	std::cout << "move assignment operator" << std::endl;
	return *this;
}

MyClass::MyClass(const std::initializer_list& list) 
{
	std::cout << "initializer_list ctor" << std::endl;
}

Quiz

As a developer you already have implemented a huge number of object instantiations. Therefore, I want to start with a quiz. Following source code shows several ways to initialize MyClass. Please take a few minutes and think about these initializations. Try to answer following question for each line of code: Which ctor and/or assignment operator is called?

int main()
{
  MyClass test1;
  MyClass test2();
  MyClass test3{};
  <pre><code>MyClass test4(42);  
  MyClass test5{ 42 };

  MyClass test6(42.5);
  MyClass test7{ 42.5 };

  MyClass test8 = 42;
  MyClass test9 = 42.5;
  MyClass test10 = { 42 };
  MyClass test11 = { 42.5 };

  MyClass test12 = MyClass();
  MyClass test13 = MyClass(42);
  MyClass test14 = MyClass{ 42 };

  MyClass test15(test1);
  MyClass test16{ test1 };

  MyClass test17 = test1;
  MyClass test18 = { test1 };

  return 0;</code></pre>
}

MyClass test1

This is the simplest way to create an object instance. The default constructor will be called. Within the default constructor you should initialize all class members, otherwise they may contain garbage values.

MyClass test2()

Like before, this looks quite simple and we may expect that the default constructor is called. But not even close. This isn’t an object initialization at all. It is a function declaration. The function “test2” without parameters and a return value “MyClass” is declared. This C++ pitfall results in the redundant use of the parentheses. For backward compatibility the meaning of this code it still as in C++98 so it is still a function declaration. To bypass this pitfall, you should not use this syntax at all. Instead use the version seen above without parenthesis or use the braces syntax introduced with C++11 (as you can see in the next paragraph). But on the other hand, it is not a big issue because it will not result in errors. If you try to use the supposed object instance you will get according errors and if you not use the “test2” you get according compiler warnings too.

MyClass test3{}

This syntax was introduced with C++11. An object initialization with braces “{}” will call the default ctor. So, this syntax is equivalent to “MyClass test1”.

MyClass test4(42)

This will call the parameterized ctor and pass the “42” as parameter. The example class is a container type and therefore this object initialization will provide a container for 42 elements initialized with default value.

MyClass test5{ 42 }

If we use the braces syntax the values inside the braces will be converted to an initializer_list and therefore the initializer_list ctor is called. If we again think about the created container object we can say this time a container with one element was created and the element value was set to 42.

So “MyClass test4(42)” and “MyClass test5{ 42 }” will have different results but the syntax is nearly the same. This is a very important aspect and unfortunately a source for errors. Therefore, we should analyze this topic in more detail.

Furthermore, the braces syntax is still allowed even if we don’t have an initializer_list ctor. In this case the parameterized ctor is called according to the values given inside the braces.

In case a parameterized ctor and an initializer_list ctor exists the initializer_list ctor is prevered and will hide the parameterized ctor. This means if we get such a collision of two possible ctor’s the one with the initializer_list is prevered automatically and we don’t get any compiler warning. This may be a source for errors.

For example, we may use a container class “MyContainer”. This container class offers a parameterized ctor with two parameters: number of elements, initial value. We can create an object instance with “MyContainer x{10, 5}”. This will create a container with 10 elements all initialized with value 5. After a couple of time, the class MyContainer will be extended by the nice feature of an initializer_list ctor. But this new feature will change the behavior of the user code which uses the class. The existing initialization “MyContainer x{10, 5}” will now create a container with two elements of value 10 and 5. To fix this error we have to change the initialization and use parenthesis to call the hidden parameterized ctor: “MyContainer x(10,5)”.

This example shows the issues you may get with the initializer_list ctor. If you add this ctor to an existing class and if you have had parameterized ctor’s so far, they will get hidden and as a result you may break user code.

You will find an according example in the standard template library. The vector class offers an initializer_list ctor and it offers a hidden parameterized ctor with two parameters: number of elements, initial value.

MyClass test6(42.5)

The example class contains a parameterized ctor with an integer value as parameter. This parameterized ctor will be called even if the parameter does not match. An according value conversion is done. This narrowing conversion is allowed for some build in types but it may result in a loss of data and therefore an compiler warning will be shown.

MyClass test7{ 42.5 }

An object instance creation with braces will call the parameterized ctor too. But in contrast to the version above with parentheses syntax, narrowing conversions are not allowed. Therefore, in our example this object instantiation will result in an error.

MyClass test8 = 42

MyClass test9 = 42.5

MyClass test10 = { 42 }

MyClass test11 = { 42.5 }

These initializations are nearly the same as the ones explained above, with the syntactical difference that we use an assignment operator. But what’s the consequence of this different syntax? Will the assignment operator of MyClass be called?

The answer is simple: The use of the assignment operator is just a syntactical difference. These initializations are therefore equal to the ones explained above (see ’test4’ to ‘test7’).

Soo for test8 and test9 the parameterized ctor is called. Test10 will call the initializer_list ctor. Test11 will result in a compiler error as the narrowing conversion is not allowed.

MyClass test12 = MyClass()

MyClass test13 = MyClass(42)

MyClass test14 = MyClass{ 42 }

Now it becomes a little more difficult. What will happen in these cases? If we look at the different parts of the syntax, for example for the first case “MyClass test12 = MyClass()” we may think following: The “MyClass()” command creates an temporary object instance by calling the default ctor and “=“ will call the assignment operator and assign the temporary object to “test12” which was previously created due to the command “MyClass test12”. But this assumption is wrong. Unfortunately, I have heard it a few times, especially when people say you can optimize you code by eliminating the supposed temporary object and the call of several ctor’s and assignments.

So, what’s happening by using this kind of syntax? Nothing special! It has the same meaning as the syntax used for “test1”, “test4“ and “test5”. Therefore, for test12 the default ctor is called, for test13 the parameterized ctor is called and for test15 the initializer_list ctor is used. No temporary object is created and the assignment operator is never called.

In summary of the examples seen so far, we can say there is no difference between the following three initializations which will all call the parameterized ctor. Same is true for the default ctor and initializer_list ctor examples seen so far.

• MyClass test4(42)
• MyClass test8 = 42
• MyClass test13 = MyClass(42)

These three spellings will create an instance of MyClass by calling the parameterized ctor. If you have read the article mentioned at the beginning you will answer back that there may be a theoretical difference. If we use explicit ctor’s the second syntax will no longer allowed. But that’s a restriction for explicit ctor’s only. In terms of common concepts, the three spellings will have the same result. But which one should be preferred? This depends on the coding guidelines of your company, your project team or your personal preferences. At the end of the article I will mention some coding guidelines.

MyClass test15(test1)

MyClass test16{ test1 }

These cases will call the copy ctor. As the given parameter is of type MyClass, the braces will not create an initializer_list.

MyClass test17 = test1

MyClass test18 = { test1 }

And again, the copy ctor will be called. As explained before, even if the syntax suggest that the assignment operator function is involved, it will never be called. So these initializations are nearly equal to the previous ones (test15 and test16) with the small difference that explicit ctor cannot be called.

Summary

As you can see there are many ways to initialize an object. These different initializations could have big differences in syntax but they have the same behavior. But unfortunately, there are some pitfalls to, like the initializer_list ctor which may hide a parameterized ctor. The braces syntax will offer uniform way to initialize objects. It should be used as preferred syntax as it can be used in nearly all cases. Following you will find some guidelines for object initializations but of course you may have your own coding guidelines or preferences.

Guidelines

Prefer object initialization with braces “{…}”, because it’s more consistent, more correct, can be used in nearly all cases and avoids old-style pitfalls at all.

In single-argument cases, especially on initialization of build in types, it is fine to omit the braces, for example “int i = 8;”.

In rare cases use parentheses “(…)” to explicitly call a ctor which is otherwise hidden by an initializer_list ctor.

When you design a class, avoid providing a ctor that ambiguously overloads with an initializer_list ctor. Users of your class should never need to use parentheses syntax to reach such a hidden ctor.

In C++ you will find several ways to initialize an object instance. For example, think about a class “MyClass” which can be constructed with a parameter. The object initialization can be done in several ways:

• MyClass x{y};
• MyClass x(y);
• MyClass x = y;
• MyClass x = {y};

But which one should be used? Do they all call the same constructor (ctor) or do these initializations lead to several results? Within the next two articles I want to think about these questions. The first article will show the several types of possible constructors and the second article will show the ways to initialize object instances.

Example object

For this article we want to create a simple class. An important task of a class is the resource management. So, the example class will contain a dynamically created memory resource which should be created by the different ctor types and released by the destructor (dtor).

Default ctor

Let’s start with the default ctor and the dtor. The default ctor does not have any parameters and it is used to initialize the class internal members.

<h1>include "stdafx.h"</h1>
<h1>include </h1>
class MyClass
{
public:
MyClass();      // default ctor
~MyClass();     // dtor

private:
int mSize;
int* mElements;
};

MyClass::MyClass()
: mSize(0)
, mElements(nullptr)
{
std::cout &lt;&lt; "default ctor" &lt;&lt; std::endl;
}

MyClass::~MyClass()
{
if (mElements)
{
delete[] mElements;
mElements = nullptr;
}
}

int main()
{
MyClass test1;      // default ctor
<pre><code>return 0;</code></pre>
}

Parameterized ctor

If we want to initialize the internal members with variable parameters, we can use a parameterized ctor. For example we can add a parameterized ctor to set the initial size of the data container.

<h1>include "stdafx.h"</h1>
<h1>include </h1>
class MyClass
{
public:
MyClass();      // default ctor
~MyClass();     // dtor
<pre><code>MyClass(const int size);        // parameterized ctor</code></pre>
private:
int mSize;
int* mElements;
};

MyClass::MyClass(const int size)
: mSize(size)
, mElements(mSize ? new int[mSize]() : nullptr)
{
std::cout &lt;&lt; "parameterized ctor" &lt;&lt; std::endl;
}

Copy ctor and copy assignment operator

Another often needed functionality is to create a copy of an existing object. This can be done by using a copy constructor. Furthermore, a copy assignment should be provided as a developer may use both ways to copy an object: copy it during creation or copy it by an assignment.

<h1>include "stdafx.h"</h1>
<h1>include </h1>
<h1>include </h1>
class MyClass
{
public:
MyClass();      // default ctor
~MyClass();     // dtor
<pre><code>MyClass(const int size);        // parameterized ctor

MyClass(const MyClass&amp; obj);        // copy ctor
MyClass&amp; operator=(const MyClass&amp; obj);     // copy assignment operator</code></pre>
private:
int mSize;
int* mElements;
};

MyClass::MyClass(const MyClass&amp; obj)
: mSize(obj.mSize)
, mElements(new int[obj.mSize])
{
std::cout &lt;&lt; "copy ctor" &lt;&lt; std::endl;
<pre><code>// create deep copy
std::copy(obj.mElements, obj.mElements + mSize, stdext::make_checked_array_iterator(mElements, mSize));</code></pre>
}

MyClass&amp; MyClass::operator=(const MyClass&amp; obj)
{
std::cout &lt;&lt; "copy assignment operator" &lt;&lt; std::endl;
<pre><code>// Self-assignment detection
if (this == &amp;obj)
{
    return *this;
}

// release resources
if (mElements)
{
    delete[] mElements;
    mElements = nullptr;
}

// create deep copy
mSize = obj.mSize;
mElements = mSize ? new int[mSize]() : nullptr;

std::copy(obj.mElements, obj.mElements + mSize, stdext::make_checked_array_iterator(mElements, mSize));

return *this;</code></pre>
}

As you can see, things become more difficult now. If we copy an object we must pay attention to several thins. At first, we should decide whether we want to create a deep or a flat copy. At next we must think about the resource management. This can be seen in the implementation of the copy assignment operator. It contains a self-assignment detection and prior to the resource creation we should releases the existing resources.

Move ctor and move assignment operator

The move ctor and operator should create a copy too. But in contrast to the copy operator we get an r-value as parameter and know that the source object is a temporary object only and will no longer be used. This will allow a more efficient resource management. As the source object in no longer used we can steal its resources instead of creating new ones.

<h1>include "stdafx.h"</h1>
<h1>include </h1>
<h1>include </h1>
class MyClass
{
public:
MyClass();      // default ctor
~MyClass();     // dtor
<pre><code>MyClass(const int size);        // parameterized ctor

MyClass(const MyClass&amp; obj);        // copy ctor
MyClass&amp; operator=(const MyClass&amp; obj);     // copy assignment operator

MyClass(MyClass&amp;&amp; obj);     // move ctor
MyClass&amp; operator=(MyClass&amp;&amp; obj);      // move assignment operator</code></pre>
private:
int mSize;
int* mElements;
};

MyClass::MyClass(MyClass&amp;&amp; obj)
{
std::cout &lt;&lt; "move ctor" &lt;&lt; std::endl;
<pre><code>// steal content of other object
mSize = obj.mSize;
mElements = obj.mElements;

// release content of other object
obj.mSize = 0;
obj.mElements = nullptr;</code></pre>
}

MyClass&amp; MyClass::operator=(MyClass&amp;&amp; obj)
{
std::cout &lt;&lt; "move assignment operator" &lt;&lt; std::endl;
<pre><code>// Self-assignment detection
if (this == &amp;obj)
{
    return *this;
}

// release resources
if (mElements)
{
    delete[] mElements;
    mElements = nullptr;
}

// steal content of other object
mSize = obj.mSize;
mElements = obj.mElements;

// release content of other object
obj.mSize = 0;
obj.mElements = nullptr;

return *this;</code></pre>
}

Again, we will add a self-assignment detection and release old resources. Furthermore, we have to reset the resources of the source object after we stole them. This will prevent the source object dtor to release these resources.

Copy & swap idiom

The copy ctor and the copy assignment operator as well as the move ctor and the move assignment operator contain some duplicate source code. There exists a common implementation technique which addresses this issue: the copy & swap idiom. This implementation technique comes with the advantage to remove this duplicate code but it will have some disadvantages too. Within this article I don’t want to explain the copy & swap idiom because it’s an own complex topic but you should keep in mind that this idiom is existing.

Initializer-list

Another important ctor type, especially for container like object, is a ctor with an initializer list. This will allow to pass an array of objects which is used to initialize the container class.

<h1>include "stdafx.h"</h1>
<h1>include </h1>
<h1>include </h1>
<h1>include </h1>
class MyClass
{
public:
MyClass();      // default ctor
~MyClass();     // dtor
<pre><code>MyClass(const int size);        // parameterized ctor

MyClass(const MyClass&amp; obj);        // copy ctor
MyClass&amp; operator=(const MyClass&amp; obj);     // copy assignment operator

MyClass(MyClass&amp;&amp; obj);     // move ctor
MyClass&amp; operator=(MyClass&amp;&amp; obj);      // move assignment operator

MyClass(const std::initializer_list&lt;int&gt;&amp; list);    //initializer_list ctor</code></pre>
private:
int mSize;
int* mElements;
};

MyClass::MyClass(const std::initializer_list&amp; list)
: mSize(list.size())
, mElements(mSize ? new int[mSize]() : nullptr)
{
std::cout &lt;&lt; "initializer_list ctor" &lt;&lt; std::endl;
<pre><code>if (list.size())
{   
    std::copy(list.begin(), list.end(), stdext::make_checked_array_iterator(mElements, mSize));
}</code></pre>
}

Use the different ctor types

The following source code contains an example console application which will create object instances. Depending on the given parameters the according ctor type is called.

int main()
{
MyClass test1;      // default ctor
<pre><code>MyClass test2(7);       // parameterized ctor

MyClass test3(test1);       // copy ctor
test3 = test1;                  // copy assignment operator

MyClass test4(std::move(test1));    // move ctor
test4 = std::move(test2);                   // move assignment operator

MyClass test5(7.1);     // parameterized ctor, warning: conversion from double to int

MyClass test6{ 1,2,3,4,5 };         //initializer_list ctor

return 0;</code></pre>
}

Implicit conversion ctor vs. explicit ctor

So far, we have implemented a couple of ctor’s for MyClass. With that ctor’s in mind do you think the following line of code will construct an object instance or will it show an error? If an object instance is created, which type of ctor is used?

MyClass test = 7;

This line of code will create a MyClass instance by calling the parameterized ctor. The parameterized ctor is also called a “conversion” ctor because it will allow implicit type conversion. In our case the MyClass instance is created based on an int value, so you can say the int value will implicit converted to an MyClass by calling the according parameterized ctor.

But maybe you don’t want to support such an implicit conversion. That may have several reasons. In my opinion such an implicit conversion looks a little bit strange and there are a lot of developers which don’t know the technical background about this line of code. Most will know that an object is created but some don’t know which ctor is used or whether it is a combination of ctor and assignment. This uncertainty and side effects on code changes may results in errors too. Therefore, you may prevent implicit conversion for some kinds of classes. In this case you have the possibility to declare the parameterized ctor as explicit. If you do so, the ctor cannot be used as implicit conversion ctor. The following source code shows an according example.

<h1>include "stdafx.h"</h1>
<h1>include </h1>
<h1>include </h1>
class MyClass1
{
public:
MyClass1() { std::cout &lt;&lt; "default ctor" &lt;&lt; std::endl; };
MyClass1(const int size) { std::cout &lt;&lt; "parameterized ctor" &lt;&lt; std::endl; };
MyClass1(const MyClass1&amp; obj) { std::cout &lt;&lt; "copy ctor" &lt;&lt; std::endl; };
};

class MyClass2
{
public:
explicit MyClass2() { std::cout &lt;&lt; "default ctor" &lt;&lt; std::endl; };
explicit MyClass2(const int size) { std::cout &lt;&lt; "parameterized ctor" &lt;&lt; std::endl; };
explicit MyClass2(const MyClass1&amp; obj) { std::cout &lt;&lt; "copy ctor" &lt;&lt; std::endl; };
};

int main()
{
MyClass1 test1 = 7;         // OK; calls parameterized ctor
MyClass1 test2 = 7.1;       // OK; calls parameterized ctor, warning: conversion from double to int
<pre><code>// MyClass2 test3 = 7;          // ERROR; implicit conversion from int to MyClass2 is not allowed
// MyClass2 test4 = 7.1;        // ERROR; implicit conversion from double to MyClass2 is not allowed
MyClass2 test6 = MyClass2(7);       // OK; calls parameterized ctor
MyClass2 test7 = MyClass2(7.1); // OK; calls parameterized ctor, warning: conversion from double to int

return 0;</code></pre>
}

MyClass2 offers an explicit ctor only. Therefore, the object instantiation cannot be done by using implicit conversion. Instead the parameterized ctor must be used explicitly. This may result in cleaner source code and may prevent errors.

Summary and outlook

Within this article we have seen the different types of constructors and got an introduction how to use them, for example to manage the resources needed by the object instance. Within the next article we will see the different ways to create an object and see which ctor is used in which situation.