Discovering Modern C++. An Intensive Course for Scientists, Engineers, and Programmers(2016)

---

For some classes, however, it is very difficult to define a default constructor, e.g., when some of the members are references or contain them. In those cases, it can be preferable to accept the before-mentioned drawbacks instead of building badly designed default constructors.

2.3.1.2 Copy Constructor

In the main function of our introductory getter-setter example (Listing 2–2), we defined two objects, one being a copy of the other. The copy operation was realized by reading and writing every member variable in the application. Better for copying objects is using a copy constructor:

class complex
{
public:
complex(const complex& c) : i(c.i), r(c.r) {}
// ...
};

int main()
{
complex z1(3.0, 2.0),
z2(z1); // copy
z3{z1}; // C++11: non-narrowing
}

If the user does not write a copy constructor, the compiler will generate one in the standard way: calling the copy constructors of all members (and base classes) in the order of their definition, just as we did in our example.

In cases like this where copying all members is precisely what we want for our copy constructor we should use the default for the following reasons:

• It is less verbose;

• It is less error-prone;

• Other people directly know what our copy constructor does without reading our code; and

• Compilers might find more optimizations.

In general, it is not advisable to use a mutable reference as an argument:

complex(complex& c) : i(c.i), r(c.r) {}

Then one can copy only mutable objects. However, there may be situations where we need this.

The arguments of the copy constructor must not be passed by value:

complex(complex c) // Error!

Please think about why for few minutes. We will tell you at the end of this section.

c++03/vector_test.cpp

There are cases where the default copy constructor does not work, especially when the class contains pointers. Say we have a simple vector class with a copy constructor:

class vector
{
public:
vector(const vector& v)
: my_size(v.my_size), data(new double[my_size])
{
for (unsigned i= 0; i < my_size; ++i)
data[i]= v.data[i];
}
// Destructor, anticipated from §2.4.2
∼vector() { delete[] data; }
// ...
private:
unsigned my_size;
double *data;
};

If we omitted this copy constructor, the compiler would not complain and voluntarily build one for us. We are glad that our program is shorter and sexier, but sooner or later we find that it behaves bizarrely. Changing one vector modifies another one as well, and when we observe this strange behavior we have to find the error in our program. This is particularly difficult because there is no error in what we have written but in what we have omitted. The reason is that we did not copy the data but only the address to it. Figure 2–1 illustrates this: when we copy v1 to v2 with the generated constructor, pointer v2.data will refer to the same data as v1.data.

Figure 2–1: Generated vector copy

Another problem we would observe is that the run-time library will try to release the same memory twice.¹ For illustration purposes, we anticipated the destructor from Section 2.4.2 here: it deletes the memory addressed by data. Since both pointers contain the same memory address, the second destructor call will fail.

1. This is an error message every programmer experiences at least once in his/her life (or he/she is not doing serious business). I hope I am wrong. My friend and proofreader Fabio Fracassi is optimistic that future programmers using modern C++ consequently will not run into such trouble. Let’s hope that he is right.

c++11/vector_unique_ptr.cpp

Since our vector is intended as the unique owner of its data, unique_ptr sounds like a better choice for data than the raw pointer:

class vector
{
// ...
std::unique_ptr<double[]> data;
};

Not only would the memory be released automatically, the compiler could not generate the copy constructor automatically because the copy constructor is deleted in unique_ptr. This forces us to provide a user implementation.

Back to our question of why the argument of a copy constructor cannot be passed by value. You have certainly figured it out in the meantime. To pass an argument by value, we need the copy constructor which we are about to define. Thus, we create a self-dependency that might lead compilers into an infinite loop. Fortunately, compilers do not stall on this and even give us a meaningful error message in this case (from the experience in the sense of Oscar Wilde that many programmers made this mistake before and some will in the future).

2.3.1.3 Conversion and Explicit Constructors

In C++, we distinguish between implicit and explicit constructors. Implicit constructors enable implicit conversion and assignment-like notation for construction. Instead of

complex c1{3.0}; // C++11 and higher
complex c1(3.0); // all standards

we can also write:

complex c1= 3.0;

or

complex c1= pi * pi / 6.0;

This notation is more readable for many scientifically educated people, while current compilers generate the same code for both notations.

The implicit conversion kicks in when one type is needed and another one is given, e.g., a double instead of a complex. Assume we have a function:²

2. The definitions of real and imag will be given soon.

double inline complex_abs(complex c)
{
return std::sqrt(real(c) * real(c) + imag(c) * imag(c));
}

and call this with a double, e.g.:

cout "|7| = " complex_abs(7.0) '\n';

The literal 7.0 is a double but there is no function overload for complex_abs accepting a double. We have, however, an overload for a complex argument and complex has a constructor accepting double. So, the complex value is implicitly built from the double literal.

The implicit conversion can be disabled by declaring the constructor as explicit:

class complex { public:
explicit complex(double nr= 0.0, double i= 0.0) : r(nr), i(i) {}
};

Then complex_abs would not be called with a double. To call this function with a double, we can write an overload for double or construct a complex explicitly in the function call:

cout "|7| = " complex_abs(complex{7.0}) '\n';

The explicit attribute is really important for some classes, e.g., vector. There is typically a constructor taking the size of the vector as an argument:

class vector
{
public:
vector(int n) : my_size(n), data(new double[my_size]) {}
};

A function computing a scalar product expects two vectors as arguments:

double dot(const vector& v, const vector& w) { ... }

This function can be called with integer arguments:

double d= dot(8, 8);

What happens? Two temporary vectors of size 8 are created with the implicit constructor and passed to the function dot. This nonsense can be easily avoided by declaring the constructor explicit.

Which constructor will be explicit is in the end the class designer’s decision. It is pretty obvious in the vector example: no right-minded programmer wants the compiler converting integers automatically into vectors.

Whether the constructor of the complex class should be explicit depends on the expected usage. Since a complex number with a zero imaginary part is mathematically identical to a real number, the implicit conversion does not create semantic inconsistencies. An implicit constructor is more convenient because a double value or literal can be used wherever a complex value is expected. Functions that are not performance-critical can be implemented only once for complex and used for double.

In C++03, the explicit attribute only mattered for single-argument constructors. From C++11 on, explicit is also relevant for constructors with multiple arguments due to uniform initialization, Section 2.3.4.

2.3.1.4 Delegation

In the examples before, we had classes with multiple constructors. Usually such constructors are not entirely different and have some code in common; i.e., there is often some redundancy. In C++03, it was typically ignored when it only concerned the setup of primitive variables; otherwise the suitable common code fragments were outsourced into a method that was then called by multiple constructors.

C++11 offers Delegating Constructors; these are constructors that call other constructors. Our complex class could use this feature instead of default values:

class complex
{
public:
complex(double r, double i) : r{r}, i{i} {}
complex(double r) : complex{r, 0.0} {}
complex() : complex{0.0} {}
...
};

Obviously, the benefit is not impressive for this small example. Delegating constructors becomes more useful for classes where the initialization is more elaborate (more complex than our complex).

2.3.1.5 Default Values for Members

Another new feature in C++11 is default values for member variables. Then we only need to set values in the constructor that are different from the defaults:

class complex
{
public:
complex(double r, double i) : r{r}, i{i} {}
complex(double r) : r{r} {}
complex() {}
...
private:
double r= 0.0, i= 0.0;
};

Again, the benefit is certainly more pronounced for large classes.

2.3.2 Assignment

In Section 2.3.1.2, we have seen that we can copy objects of user classes without getters and setters—at least during construction. Now, we want to copy into existing objects by writing:

x= y;
u= v= w= x;

To this end, the class must provide an assignment operator (or refrain from stopping the compiler to generate one). As usual, we consider first the class complex. Assigning a complex value to a complex variable requires an operator like

complex& operator=(const complex& src)
{
r= src.r; i= src.i;
return *this;
}

Evidently, we copy the members r and i. The operator returns a reference to the object for enabling multiple assignments. this is a pointer to the object itself, and since we need a reference, we dereference the this pointer. The operator that assigns values of the object’s type is calledCopy Assignment and can be synthesized by the compiler. In our example, the generated code would be identical to ours and we could omit our implementation here.

What happens if we assign a double to a complex?

c= 7.5;

It compiles without the definition of an assignment operator for double. Once again, we have an implicit conversion: the implicit constructor creates a complex on the fly and assigns this one. If this becomes a performance issue, we can add an assignment for double:

complex& operator=(double nr)
{
r= nr; i= 0;
return *this;
}

As before, vector’s synthesized operator is not satisfactory because it only copies the address of the data and not the data itself. The implementation is very similar to the copy constructor:

1 vector& operator=(const vector& src)
2 {
3 if (this == &src)
4 return *this;
5 assert(my_size == src.my_size);
6 for (int i= 0; i < my_size; ++i)
7 data[i]= src.data[i];
8 return *this;
9 }

It is advised [45, p. 94] that copy assignment and constructor be consistent to avoid utterly confused users.

An assignment of an object to itself (source and target have the same address) can be skipped (lines 3 and 4). In line 5, we test whether the assignment is a legal operation by checking the equality of the vector sizes. Alternatively the assignment could resize the target if the sizes are different. This is a technically legitimate option but scientifically rather questionable. Just think of a context in mathematics or physics where a vector space all of a sudden changes its dimension.

2.3.3 Initializer Lists

C++11 introduces the Initializer Lists as a new feature—not to be confused with “member initialization list” (§2.3.1). To use it, we must include the header <initializer_list>. Although this feature is orthogonal to the class concept, the constructor and assignment operator of a vector are excellent use cases, making this a suitable location for introducing initializer lists. It allows us to set all entries of a vector at the same time (up to reasonable sizes).

Ordinary C arrays can be initialized entirely within their definition:

float v[]= {1.0, 2.0, 3.0};

This capability is generalized in C++11 so that any class may be initialized with a list of values (of the same type). With an appropriate constructor, we could write:

vector v= {1.0, 2.0, 3.0};

or

vector v{1.0, 2.0, 3.0};

We could also set all vector entries in an assignment:

v= {1.0, 2.0, 3.0};

Functions that take vector arguments could be called with a vector that is set up on the fly:

vector x= lu_solve(A, vector{1.0, 2.0, 3.0});

The previous statement solves a linear system for the vector (1, 2, 3)^T with an LU factorization on A.

To use this feature in our vector class, we need a constructor and an assignment accepting initializer_list<double> as an argument. Lazy people can implement the constructor only and use it in the copy assignment. For demonstration and performance purposes, we will implement both. It also allows us to verify in the assignment that the vector size matches:

#include <initializer_list>
#include <algorithm>

class vector
{
// ...
vector(std::initializer_list<double> values)
: my_size(values.size()), data(new double[my_size])
{
std::copy(std::begin(values), std::end(values),
std::begin(data));
}

self& operator=(std::initializer_list<double> values)
{
assert(my_size == values.size());
std::copy(std::begin(values), std::end(values),
std::begin(data));
return *this;
}
};

To copy the values within the list into our data, we use the function std::copy from the standard library. This function takes three iterators³ as arguments. These three arguments represent the begin and the end of the input and the begin of the output. The free functions begin andend were introduced in C++11. In C++03, we have to use the corresponding member functions, e.g., values.begin().

3. Which are kind of generalized pointers; see §4.1.2.

2.3.4 Uniform Initialization

Braces {} are used in C++11 as universal notation for all forms of variable initialization by

• Initializer-list constructors,

• Other constructors, or

• Direct member setting.

The latter is only allowed for arrays and classes if all (non-static) variables are public and the class has no user-defined constructor.⁴ Such types are called Aggregates and setting their values with braced lists accordingly Aggregate Initialization.

4. Further conditions are that the class has no base classes and no virtual functions (§6.1).

Assuming we would define a kind of sloppy complex class without constructors, we could initialize it as follows:

struct sloppy_complex
{
double r, i;
};

sloppy_complex z1{3.66, 2.33},
z2= {0, 1};

Needless to say, we prefer using constructors over the aggregate initialization. However, it comes in handy when we have to deal with legacy code.

The complex class from this section which contains constructors can be initialized with the same notation:

complex c{7.0, 8}, c2= {0, 1}, c3= {9.3}, c4= {c};
const complex cc= {c3};

The notation with = is not allowed when the relevant constructor is declared explicit.

There remain the initializer lists that we introduced in the previous section. Using a list as an argument of uniform initialization would actually require double braces:

vector v1= {{1.0, 2.0, 3.0}},
v2{{3, 4, 5}};

To simplify our life, C++11 provides Brace Elision in a uniform initializer; i.e., braces can be omitted and the list entries are passed in their given order to constructor arguments or data members. So, we can shorten the declaration to

vector v1= {1.0, 2.0, 3.0},
v2{3, 4, 5};

Brace elision is a blessing and a curse. Assume we integrated our complex class in the vector to implement a vector_complex which we can conveniently set up:

vector_complex v= {{1.5, -2}, {3.4}, {2.6, 5.13}};

However, the following example:

vector_complex v1d= {{2}};
vector_complex v2d= {{2, 3}};
vector_complex v3d= {{2, 3, 4}};

std::cout "v1d is " v1d std::endl; ...

might be a bit surprising:

v1d is [(2,0)]
v2d is [(2,3)]
v3d is [(2,0), (3,0), (4,0)]

In the first line, we have one argument so the vector contains one complex number which is initialized with the one-argument constructor (imaginary part is 0). The next statement creates a vector with one element whose constructor is called with two arguments. This scheme cannot continue obviously: complex has no constructor with three arguments. So, here we switch to multiple vector entries that are constructed with one argument each. Some more experiments are given for the interested reader in Appendix A.4.2.

Another application of braces is the initialization of member variables:

class vector
{
public:
vector(int n)
: my_size{n}, data{new double[my_size]} {}
...
private:
unsigned my_size;
double *data;
};

This protects us from occasional sloppiness: in the example above we initialize an unsigned member with an int argument. This narrowing is denounced by the compiler and we will substitute the type accordingly:

vector(unsigned n) : my_size{n}, data{new double[my_size]} {}

We already showed that initializer lists allow us to create non-primitive function arguments on the fly, e.g.:

double d= dot(vector{3, 4, 5}, vector{7, 8, 9});

When the argument type is clear—when only one overload is available, for instance—the list can be passed typeless to the function:

double d= dot({3, 4, 5}, {7, 8, 9});

Accordingly, function results can be set by the uniform notation as well:

complex subtract(const complex& c1, const complex& c2)
{
return {c1.r - c2.r, c1.i - c2.i};
}

The return type of this function is a complex and we initialize it with a two-argument braced list.

In this section, we demonstrated the possibilities of uniform initialization and illustrated some risks. We are convinced that it is a very useful feature but one that should be used with some care for tricky corner cases.

2.3.5 Move Semantics

Copying large amounts of data is expensive, and people use a lot of tricks to avoid unnecessary copies. Several software packages use shallow copy. That would mean for our vector example that we only copy the address of the data but not the data itself. As a consequence, after the assignment:

v= w;

the two variables contain pointers to the same data in memory. If we change v[7], then we also change w[7] and vice versa. Therefore, software with shallow copy usually provides a function for explicitly calling a deep copy:

copy(v, w);

This function must be used instead of the assignment every time variables are assigned. For temporary values—for instance, a vector that is returned as a function result—the shallow copy is not critical since the temporary is not accessible otherwise and we have no aliasing effects. The price for avoiding the copies is that the programmer must pay utter attention that in the presence of aliasing, memory is not released twice; i.e., reference counting is needed.

On the other hand, deep copies are expensive when large objects are returned as function results. Later, we will present a very efficient technique to avoid copies (see §5.3). Now, we introduce another feature from C++11 for it: Move Semantics. The idea is that variables (in other words all named items) are copied deeply and temporaries (objects that cannot be referred to by name) transfer their data.

This raises the question: How to tell the difference between temporary and persistent data? The good news is: the compiler does this for us. In the C++ lingo, the temporaries are called Rvalues because they can only appear on the right side in an assignment. C++11 introduces rvalue references that are denoted by two ampersands &&. Values with a name, so-called lvalues, cannot be passed to rvalue references.

2.3.5.1 Move Constructor

By providing a move constructor and a move assignment, we can assure that rvalues are not expensively copied:

class vector
{
// ...
vector(vector&& v)
: my_size(v.my_size), data(v.data)
{
v.data= 0;
v.my_size= 0;
}
};

The move constructor steals the data from its source and leaves it in an empty state.

An object that is passed as an rvalue to a function is considered expired after the function returns. This means that all data can be entirely random. The only requirement is that the destruction of the object (§2.4) must not fail. Utter attention must be paid to raw pointers (as usual). They must not point to random memory so that the deletion fails or some other user data is freed. If we would have left the pointer v.data unchanged, the memory would be released when v goes out of scope and the data of our target vector would be invalidated. Usually a raw pointer should benullptr (0 in C++03) after a move operation.

Note that an rvalue reference like vector&& v is not an rvalue itself but an lvalue as it possesses a name. If we wanted to pass our v to another method that helps the move constructor with the data robbery, we would have to turn it into an rvalue again with the standard functionstd::move (see §2.3.5.4).

2.3.5.2 Move Assignment

The move assignment can be implemented in a simple manner by swapping the pointers to the data:

class vector
{
// ...
vector& operator=(vector&& src)
{
assert(my_size == 0 || my_size == src.my_size);
std::swap(data, src.data);
return *this;
}
};

This relieves us from releasing our own existing data because this is done when the source is destroyed.

Say we have an empty vector v1 and a temporarily created vector v2 within function f() as depicted in the upper part of Figure 2–2. When we assign the result of f() to v1:

v1= f(); // f returns v2

Figure 2–2: Moved data

the move assignment will swap the data pointers so that v1 contains the values of v2 afterward while the latter is empty as in the lower part of Figure 2–2.

2.3.5.3 Copy Elision

If we add logging in these two functions, we might realize that our move constructor is not called as often as we thought. The reason for this is that modern compilers provide an even better optimization than stealing the data. This optimization is called Copy Elision where the compiler omits a copy of the data and modifies the generation of the data such that it is immediately stored to the target address of the copy operation.

Its most important use case is Return Value Optimization (RVO), especially when a new variable is initialized with a function result like

inline vector ones(int n)
{
vector v(n);
for (unsigned i= 0; i < n; ++i)
v[i]= 1.0;
return v;
}
...
vector w(ones(7));

Instead of constructing v and copying (or moving) it to w at the end of the function, the compiler can create w immediately and perform all operations directly on it. The copy (or move) constructor is never called. We simply check this with a log output or a debugger.

Copy elision was already available in many compilers before move semantics. However, that should not mean that move constructors are useless. The rules for moving data are mandatory by the standard whereas the RVO optimization is not guaranteed. Often minor details can turn it off, for instance, if the function has multiple return statements.

2.3.5.4 Where We Need Move Semantics

One situation where a move constructor is definitely used is with the function std::move. Actually this function does not move, it only casts an lvalue to an rvalue. In other words, it pretends that the variable is a temporary; i.e., it makes it movable. As a consequence, subsequent constructors or assignments will call the overload for an rvalue reference, as in the following code snippet:

vector x(std::move(w));
v= std::move(u);

In the first line, x steals the data of w and leaves it as an empty vector. The second statement will swap v and u.

Our move constructor and assignment are not perfectly consistent when used with std::move. As long as we deal only with true temporaries, we would not see the difference. However, for stronger consistency we can also leave the source of a move assignment in an empty state:

class vector
{
// ...
vector& operator=(vector&& src)
{
assert(my_size == src.my_size);
delete[] data;
data= src.data;
src.data= nullptr;
src.my_size= 0;
return *this;
}
};

Another take on this is that objects are considered expired after std::move. Phrased differently, they are not dead yet but retired, and it does not matter what value they have as long as they are in a legal state (i.e., the destructor must not crash).

A nice application of move semantics is the default implementation std::swap in C++11 and higher; see Section 3.2.3.

2.4 Destructors

A destructor is a function that is called every time when an object is destroyed, for example:

∼complex()
{
std::cout "So long and thanks for the fish.\n";
}

Since the destructor is the complementary operation of the default constructor, it uses the notation for the complement (∼). Opposed to the constructor, there is only one single overload and arguments are not allowed.

2.4.1 Implementation Rules

There are two very important rules:

1. Never throw an exception in a destructor! It is likely that your program will crash and the exception will never be caught. In C++11 or higher, it is always treated as a run-time error which aborts the execution (destructors are implicitly declared noexcept, §1.6.2.4). In C++03, what happens depends on the compiler implementation, but a program abortion is the most likely reaction.

2. If a class contains a virtual function, the destructor should be virtual, too. We come back to this in Section 6.1.3.

2.4.2 Dealing with Resources Properly

What we do in a destructor is our free choice; we have no limitations from the language. Practically, the main task of a destructor is releasing the resources of an object (memory, file handles, sockets, locks, . . . ) and cleaning up everything related to the object that is not needed any longer in the program. Because a destructor must not throw exceptions, many programmers are convinced that releasing resources should be the only activity of a destructor.

c++03/vector_test.cpp

In our example, there is nothing to do when a complex number is destroyed and we can omit the destructor. A destructor is needed when the object acquires resources like memory. In such cases, the memory or the other resource must be released in the destructor:

class vector
{
public:
// ...
∼vector()
{
delete[] data;
}
// ...
private:
unsigned my_size;
double *data;
};

Note that delete already tests whether a pointer is nullptr (0 in C++03). Similarly, files that are opened with old C handles require explicit closing (and this is only one reason for not using them).

2.4.2.1 Resource Acquisition Is Initialization

Resource Acquisition Is Initialization (RAII) is a paradigm mainly developed by Bjarne Stroustrup and Andrew Koenig. The idea is tying resources to objects and using the mechanism of object construction and destruction to handle resources automatically in programs. Each time we want to acquire a resource, we do so by creating an object that owns it. Whenever the object goes out of scope, the resource (memory, file, socket, . . . ) is released automatically, as in our vector example above.

Imagine a program that allocates 37,186 memory blocks in 986 program locations. Can we be sure that all the memory blocks are freed? And how much time will we spend to get to this certainty or at least to an acceptable level of confidence? Even with tools like valgrind (§B.3), we can only test the absence of memory leaks for a single run but cannot guarantee in general that memory is always released. On the other hand, when all memory blocks are allocated in constructors and freed in destructors, we can be sure that no leaks exist.

2.4.2.2 Exceptions

Releasing all resources is even more challenging when exceptions are thrown. Whenever we detect a problem, we have to release all resources acquired so far before we throw the exception. Unfortunately, this is not limited to resources in the current scope but extends to those of surrounding scopes depending on where the exception is caught. This means that changing the error handling needs tedious adaption of the manual resource management.

2.4.2.3 Managed Resources

All the problems mentioned before can be solved by introducing classes that manage the resources. C++ already offers such managers in the standard library. File streams manage the file handles from C. unique_ptr and shared_ptr handle memory in a leak-free, exception-safe manner.⁵ Also in our vector example, we can benefit from unique_ptr by not needing to implement a destructor.

5. Only cyclic references need special treatment.

2.4.2.4 Managing Ourselves

The smart pointers show that there can be different treatments of a resource type. However, when none of the existing classes handles a resource in the fashion we want, it is a great occasion to entertain ourselves writing a resource manager tailored to our needs.

When we do so, we should not manage more than one resource in a class. The motivation for this guideline is that exceptions can be thrown in constructors, and it is quite tedious to write the constructor in a way that guarantees that all resources acquired so far are released.

Thus, whenever we write a class that deals with two resources (even of the same type) we should introduce a class that manages one of the resources. Better yet, we should write managers for both resources and separate the resource handling entirely from the scientific content. Even in the case that an exception is thrown in the middle of the constructor, we have no problem with leaking resources since the destructors of their managers are called automatically and will take care of it.

The term “RAII” puts linguistically more weight on the initialization. However, the finalization is even more important technically. It is not mandatory that a resource is acquired in a constructor. This can happen later in the lifetime of an object. Fundamental is that one single object is responsible for the resource and releases it at the end of its lifetime. Jon Kalb calls this approach an application of the Single Responsibility Principle (SRP), and it is worthwhile to see his talk, which is available on the web.

2.4.2.5 Resource Rescue

In this section, we introduce a technique for releasing resources automatically even when we use a software package with explicit resource handling. We will demonstrate the technique with the Oracle C++ Call Interface (OCCI) [33] for accessing an Oracle database from a C++ program. This example allows us to show a realistic application, and we assume that many scientists and engineers have to deal with databases from time to time. Although the Oracle database is a commercial product, our example can be tested with the free Express edition.

OCCI is a C++ extension of the C library OCI and adds only a thin layer with some C++ features on top while keeping the entire software architecture in C style. Sadly, this applies to most inter-language interfaces of C libraries. Since C does not support destructors, one cannot establish RAII and resources must be released explicitly.

In OCCI, we first have to create an Environment which can be used to establish a Connection to the database. This in turn allows us to write a Statement that returns a ResultSet. All these resources are represented by raw pointers and must be released in reverse order.

As an example, we look at Table 2–1 where our friend Herbert keeps track of his solutions to (allegedly) unsolved mathematical problems. The second column indicates whether he is certain to deserve an award for his work. For size reasons, we cannot print the complete list of his tremendous discoveries here.

Table 2–1: Herbert’s Solutions

c++03/occi_old_style.cpp

From time to time, Herbert looks up his award-worthy discoveries with the following C++ program:

#include <iostream>
#include <string>
#include <occi.h>

using namespace std; // import names (§3.2.1)
using namespace oracle::occi;

int main()
{
string dbConn= "172.17.42.1", user= "herbert",
password= "NSA_go_away";
Environment *env = Environment::createEnvironment();
Connection *conn = env->createConnection(user, password,
dbConn);
string query= "select problem from my_solutions"
" where award_worthy != 0";
Statement *stmt = conn->createStatement(query);
ResultSet *rs = stmt->executeQuery();

while (rs->next())
cout rs->getString(1) endl;
stmt->closeResultSet(rs);
conn->terminateStatement(stmt);
env->terminateConnection(conn);
Environment::terminateEnvironment(env);
}

This time, we cannot blame Herbert for his old-style programming; it is forced by the library. Let us have a look at the code. Even for people not familiar with OCCI, it is evident what happens. First, we acquire the resources, then we iterate over Herbert’s ingenious achievements, and finally we release the resources in reverse order. We highlighted the resource release operations as we will have to pay closer attention to them.

The release technique works reasonably well when our (or Herbert’s) program is a monolithic block as above. The situation changes entirely when we try building functions with queries:

ResultSet *rs = makes_me_famous();
while (rs->next())
cout rs->getString(1) endl;

ResultSet *rs2 = needs_more_work();
while (rs2->next())
cout rs2->getString(1) endl;

Now we have result sets without the corresponding statements to close them; they were declared within the query functions and are out of scope now. Thus, for every object we have to keep additionally the object that was used for its generation. Sooner or later this becomes a nightmare of dependencies with an enormous potential for errors.

c++11/occi_resource_rescue.cpp

The question is: How can we manage resources that depend on other resources? The solution is to use deleters from unique_ptr or shared_ptr. They are called whenever managed memory is released. An interesting aspect of deleters is that they are not obliged to actually release the memory. We will explore this liberty to manage our resources. The Environment has the easiest handling because it does not depend on another resource:

struct environment_deleter {
void operator()( Environment* env )
{ Environment::terminateEnvironment(env); }
};

shared_ptr<Environment> environment(
Environment::createEnvironment(), environment_deleter {});

Now, we can create as many copies of the environment as we like and have the guarantee that the deleter executing terminateEnvironment(env) is called when the last copy goes out of scope.

A Connection requires an Environment for its creation and termination. Therefore, we keep a copy in connection_deleter:

struct connection_deleter
{
connection_deleter(shared_ptr<Environment> env)
: env(env) {}
void operator()(Connection* conn)
{ env->terminateConnection(conn); }
shared_ptr<Environment> env;
};

shared_ptr<Connection> connection(environment->createConnection(...),
connection_deleter{environment});

Now, we have the guarantee that the Connection is terminated when it is not needed any longer. Having a copy of the Environment in the connection_deleter ensures that it is not terminated as long as a Connection exists.

We can handle the database more conveniently when we create a manager class for it:

class db_manager
{
public:
using ResultSetSharedPtr= std::shared_ptr<ResultSet>;

db_manager(string const& dbConnection, string const& dbUser,
string const& dbPw)
: environment(Environment::createEnvironment(),
environment_deleter{}),
connection(environment->createConnection(dbUser, dbPw,
dbConnection),
connection_deleter{environment} )
{}
// some getters ...
private:
shared_ptr<Environment> environment;
shared_ptr<Connection> connection;
};

Note that the class has no destructor since the members are managed resources now.

To this class, we can add a query method that returns a managed ResultSet:

struct result_set_deleter
{
result_set_deleter(shared_ptr<Connection> conn,
Statement* stmt)
: conn(conn), stmt(stmt) {}
void operator()( ResultSet *rs ) // call op. like in (§3.8)
{
stmt->closeResultSet(rs);
conn->terminateStatement(stmt);
}
shared_ptr<Connection> conn;
Statement* stmt;
};

class db_manager
{
public:
// ...
ResultSetSharedPtr query(const std::string& q) const
{
Statement *stmt= connection->createStatement(q);
ResultSet *rs= stmt->executeQuery();
auto deleter= result_set_deleter{connection, stmt};
return ResultSetSharedPtr{rs, deleter};
}
};

Thanks to this new method and our deleters, the application becomes as easy as

int main()
{
db_manager db("172.17.42.1", "herbert", "NSA_go_away");
auto rs= db.query("select problem from my_solutions "
" where award_worthy != 0");
while (rs->next())
cout rs->getString(1) endl;
}

The more queries we have, the more our effort pays off. Not being ashamed to repeat ourselves: all resources are implicitly released.

The careful reader has realized that we violated the single-responsibility principle. To express our gratitude for this discovery we invite you to improve our design in Exercise 2.8.4.

2.5 Method Generation Résumé

C++ has six methods (four in C++03) with a default 'margin-top:4.0pt;margin-right:0cm;margin-bottom:4.0pt; margin-left:40.0pt;text-indent:-9.0pt;line-height:normal'>• Default constructor

• Copy constructor

• Move constructor (C++11 or higher)

• Copy assignment

• Move assignment (C++11 or higher)

• Destructor

The code for those can be generated by the compiler—saving us from boring routine work and thus preventing oversights.

There is a fair amount of detail involved in the rules determining which method is generated implicitly. These details are covered in more detail in Appendix A, Section A.5. Here we only want to give you our final conclusions for C++11 and higher: