Introduction

Unlike a few other object-oriented programming languages, C++ programming doesn't allow a constructor to call another constructor of the same class. Consequently, programmers are often forced to repeat the same initialization code in every constructor. Such duplicate code introduces maintenance problems and compromises code readability. Fortunately, in 2006 the C++ programming standards committee voted into the Working Draft a proposal for adding delegating constructors to C++0x. In the following section I will show how to implement delegating constructors to reduce the amount of boilerplate code and simplify the design of your classes.

Duplicating Constructor Code

A C++ class may have more than one constructor. In many cases, those constructors perform identical initialization steps such as allocating memory and zeroing data members. In the following example, class M defines two constructors that are nearly identical:

Calling init()

Technically, constructor #1 performs exactly the same operations as does constructor #2 except the initialization of the member x. Ideally, you would want to move the identical bits of code into a single constructor. In C++03, the common workaround is to define a private member function called init(). Every constructor will call that function. Here's a revised version of the same class that uses init():

Although init() eliminates code reduplication, it isn't an ideal solution. The name init() is just a convention; other programmers might choose different names for an initialization function or they might forget to call that function. In addition, the generated code is less efficient because the compiler applies certain optimizations to constructors' member initialization lists which it can't apply to an ordinary function.

Using Target Constructors

C++0x offers a neat solution to this problem. You can delegate the task of initialization to a single constructor known as the target constructor. Other constructors known as delegating constructors will invoke the target constructor first, and then perform additional operations if necessary.

Syntactically, a target constructor looks like an ordinary constructor. There's no explicit syntactic cue designating it as a target constructor. This is convenient because the same constructor can be used both as a target for another constructor, or as a delegating constructor, as you will shortly see. The delegating constructor invokes its target constructor like this:

The member initialization list of constructor #2 invokes the target constructor #1, which initializes three data members of M. Inside the body of the delegating constructor you can perform additional steps -- writing to the console, for instance.

As said earlier, a delegating constructor may also serve as a target constructor. Consider:

Constructor #3 invokes constructor #2. However, constructor #2 is also a delegating constructor that invokes the target constructor #1. In other words, constructor #2 is both a target constructor and a delegating constructor:

M m1(14.5); //invoke #3
M m2(0); //invoke #1
M m3; //invoke #2

To determine which constructors are invoked for every one of the three objects m1, m2, m3, all you have to do is find out which constructor is called first. In the case of m1, the argument 14.5 is of type double. Hence, constructor #3 is called first. In the case of m2, the argument is of type int, hence constructor #2 is called first.

If you're worried about performance, banish any concern. The compiler is able to optimize the generated code for delegating constructors quite effectively.

Conclusion

Delegating constructors offer a simple and intuitive solution to the problem of repeated initialization code. Presently, IBM's XLC++ 11.1 is among the few pioneers supporting delegating constructors. GCC also supports this feature but you will need to download a separate patch.

Top White Papers and Webcasts

Live Event Date: March 19, 2015 @ 1:00 p.m. ET / 10:00 a.m. PT
The 2015 Enterprise Mobile Application Survey asked 250 mobility professionals what their biggest mobile challenges are, how many employees they are equipping with mobile apps, and their methods for driving value with mobility.
Join Dan Woods, Editor and CTO of CITO Research, and Alan Murray, SVP of Products at Apperian, as they break down the results of this survey and discuss how enterprises are using mobile application management and private …

On-demand Event
Event Date: February 12, 2015
The evolution of systems engineering with the SysML modeling language has resulted in improved requirements specification, better architectural definition, and better hand-off to downstream engineering. Agile methods have proven successful in the software domain, but how can these methods be applied to systems engineering? Check out this webcast and join Bruce Powel Douglass, author of Real-Time Agility, as he discusses how agile methods have had a tremendous …