• Table of Contents
• Previous Chapter
• Next Chapter

Chapter 7: Classes

Don't hesitate to send in feedback: send an e-mail if you like the C++ Annotations; if you think that important material was omitted; if you find errors or typos in the text or the code examples; or if you just feel like e-mailing. Send your e-mail to Frank B. Brokken.

Please state the document version you're referring to, as found in the title (in this document: 10.3.0) and please state chapter and paragraph name or number you're referring to.

All received mail is processed conscientiously, and received suggestions for improvements are usually processed by the time a new version of the Annotations is released. Except for the incidental case I will normally not acknowledge the receipt of suggestions for improvements. Please don't interpret this as me not appreciating your efforts.

The C programming language offers two methods for structuring data of different types. The C struct holds data members of various types, and the C union also defines data members of various types. However, a union's data members all occupy the same location in memory and the programmer may decide on which one to use.

In this chapter classes are introduced. A class is a kind of struct, but its contents are by default inaccessible to the outside world, whereas the contents of a C++ struct are by default accessible to the outside world. In C++ structs find little use: they are mainly used to aggregate data within the context of classes or to define elaborate return values. Often a C++ struct merely contains plain old data (POD, cf. section 9.9). In C++ the class is the main data structuring device, by default enforcing two core concepts of current-day software engineering: data hiding and encapsulation (cf. sections 3.2.1 and 7.1.1).

The union is another data structuring device the language offers. The traditional C union is still available, but C++ also offers unrestricted unions. Unrestricted unions are unions whose data fields may be of class types. The C++ Annotations covers these unrestricted unions in section 12.6, after having introduced several other new concepts of C++,

C++ extends the C struct and union concepts by allowing the definition of member functions (introduced in this chapter) within these data types. Member functions are functions that can only be used with objects of these data types or within the scope of these data types. Some of these member functions are special in that they are always, usually automatically, called when an object starts its life (the so-called constructor) or ends its life (the so-called destructor). These and other types of member functions, as well as the design and construction of, and philosophy behind, classes are introduced in this chapter.

We step-by-step construct a class Person, which could be used in a database application to store a person's name, address and phone number.

Let's start by creating a class Person right away. From the onset, it is important to make the distinction between the class interface and its implementation. A class may loosely be defined as `a set of data and all the functions operating on those data'. This definition is later refined but for now it is sufficient to get us started.

A class interface is a definition, defining the organization of objects of that class. Normally a definition results in memory reservation. E.g., when defining int variable the compiler ensures that some memory is reserved in the final program storing variable's values. Although it is a definition no memory is set aside by the compiler once it has processed the class definition. But a class definition follows the one definition rule: in C++ entities may be defined only once. As a class definition does not imply that memory is being reserved the term class interface is preferred instead.

Class interfaces are normally contained in a class header file, e.g., person.h. We'll start our class Person interface here (cf section 7.7 for an explanation of the const keywords behind some of the class's member functions):

    #include <string>

    class Person
    {
        std::string d_name;         // name of person
        std::string d_address;      // address field
        std::string d_phone;        // telephone number
        size_t      d_mass;         // the mass in kg.

        public:                     // member functions
            void setName(std::string const &name);
            void setAddress(std::string const &address);
            void setPhone(std::string const &phone);
            void setMass(size_t mass);

            std::string const &name()    const;
            std::string const &address() const;
            std::string const &phone()   const;
            size_t mass()                const;
    };

The member functions that are declared in the interface must still be implemented. The implementation of these members is properly called their definition.

In addition to the member function a class defines the data manipulated by the member functions. These data are called the data memberdata members. In Person they are d_name, d_address, d_phone and d_mass. Data members should be given private access rights. Since the class uses private access rights by default they may simply be listed at the top of the interface.

All communication between the outer world and the class data is routed through the class's member functions. Data members may receive new values (e.g., using setName) or they may be retrieved for inspection (e.g., using name). Functions merely returning values stored inside the object, not allowing the caller to modify these internally stored values, are called accessors.

Syntactically there is only a marginal difference between a class and a struct. Classes by default define private members, structs define public members. Conceptually, though, there are differences. In C++ structs are used in the way they are used in C: to aggregate data, which are all freely accessible. Classes, on the other hand, hide their data from access by the outside world (which is aptly called data hiding) and offer member functions to define the communication between the outer world and the class's data members.

Following Lakos (Lakos, J., 2001) Large-Scale C++ Software Design (Addison-Wesley) I suggest the following setup of class interfaces:

• All data members have private access rights, and are placed at the top of the interface.
• All data members start with d_, followed by a name suggesting their meaning (in chapter 8 we'll also encounter data members starting with s_).
• Non-private data members do exist, but one should be hesitant to define non-private access rights for data members (see also chapter 13).
• Two broad categories of member functions are manipulators and accessors. Manipulators allow the users of objects to modify the internal data of the objects. By convention, manipulators start with set. E.g., setName.
• With accessors, a get-prefix is still frequently encountered, e.g., getName. However, following the conventions promoted by the Qt (see http://www.trolltech.com) Graphical User Interface Toolkit, the get-prefix is now deprecated. So, rather than defining the member getAddress, it should simply be named address.
• Normally (exceptions exist) the public member functions of a class are listed first, immediately following the class's data members. They are the important elements of the interface as they define the features the class is offering to its users. It's a matter of convention to list them high up in the interface. The keyword private is needed beyond the public members to switch back from public members to private access rights which nicely separates the members that may be used `by the general public' from the class's own support members.

Finally, referring back to section 3.1.2 that

    using namespace std;

    #include <iostream>
    #include "person.h"

    using namespace std;

    int main()
    {
        ...
    }

7.1: The constructor

Constructor are recognized by their names which is equal to the class name. Constructors do not specify return values, not even void. E.g., the class Person may define a constructor Person::Person(). The C++ run-time system ensures that the constructor of a class is called when a variable of the class is defined. It is possible to define a class lacking any constructor. In that case the compiler defines a default constructor that is called when an object of that class is defined. What actually happens in that case depends on the data members that are defined by that class (cf. section 7.3.1).

Objects may be defined locally or globally. However, in C++ most objects are defined locally. Globally defined objects are hardly ever required and are somewhat deprecated.

When a local object is defined its constructor is called every time the function is called. The object's constructor is activated at the point where the object is defined (a subtlety is that an object may be defined implicitly as, e.g., a temporary variable in an expression).

When an object is defined as a static object it is constructed when the program starts. In this case its constructor is called even before the function main starts. Example:

    #include <iostream>
    using namespace std;

    class Demo
    {
        public:
            Demo();
    };

    Demo::Demo()
    {
        cout << "Demo constructor called\n";
    }

    Demo d;

    int main()
    {}

    /*
        Generated output:
    Demo constructor called
    */

The program contains one global object of the class Demo with main having an empty body. Nonetheless, the program produces some output generated by the constructor of the globally defined Demo object.

Constructors have a very important and well-defined role. They must ensure that all the class's data members have sensible or at least well-defined values once the object has been constructed. We'll get back to this important task shortly. The default constructor has no argument. It is defined by the compiler unless another constructor is defined and unless its definition is suppressed (cf. section 7.6). If a default constructor is required in addition to another constructor then the default constructor must explicitly be defined as well. C++ provides special syntax to do that as well, which is also covered by section 7.6.

7.1.1: A first application

Whenever an object is defined the class's constructor(s) ensure that its data members are given `sensible' values. Thus, objects never suffer from uninitialized values. Data members may be given new values, but that should never be directly allowed. It is a core principle (called data hiding) of good class design that its data members are private. The modification of data members is therefore fully controlled by member functions and thus, indirectly, by the class-designer. The class encapsulates all actions performed on its data members and due to this encapsulation the class object may assume the `responsibility' for its own data-integrity. Here is a minimal definition of Person's manipulating members:

    #include "person.h"                 // given earlier
    using namespace std;

    void Person::setName(string const &name)
    {
        d_name = name;
    }
    void Person::setAddress(string const &address)
    {
        d_address = address;
    }
    void Person::setPhone(string const &phone)
    {
        d_phone = phone;
    }
    void Person::setMass(size_t mass)
    {
        d_mass = mass;
    }

It's a minimal definition in that no checks are performed. But it should be clear that checks are easy to implement. E.g., to ensure that a phone number only contains digits one could define:

    void Person::setPhone(string const &phone)
    {
        if (phone.find_first_not_of("0123456789") == string::npos)
            d_phone = phone;
        else
            cout << "A phone number may only contain digits\n";
    }

To prevent backdoors we must also make sure that the data member is not modifiable through an accessor's return value. For values of built-in primitive types that's easy, as they are usually returned by value, which are copies of the values found in variables. But since objects may be fairly large making copies are usually prevented by returning objects by reference. A backdoor is created by returning a data member by reference, as in the following example, showing the allowed abuse below the function definition:

    string &Person::name() const
    {
        return d_name;
    }

    Person somebody;
    somebody.setName("Nemo");

    somebody.name() = "Eve";    // Oops, backdoor changing the name

    #include "person.h"                 // given earlier
    using namespace std;

    string const &Person::name() const
    {
        return d_name;
    }
    string const &Person::address() const
    {
       return d_address;
    }
    string const &Person::phone() const
    {
       return d_phone;
    }
    size_t Person::mass() const
    {
       return d_mass;
    }

The Person class interface remains the starting point for the class design: its member functions define what can be asked of a Person object. In the end the implementation of its members merely is a technicality allowing Person objects to do their jobs.

The next example shows how the class Person may be used. An object is initialized and passed to a function printperson(), printing the person's data. Note the reference operator in the parameter list of the function printperson. Only a reference to an existing Person object is passed to the function, rather than a complete object. The fact that printperson does not modify its argument is evident from the fact that the parameter is declared const.

    #include <iostream>
    #include "person.h"                 // given earlier
    using namespace std;

    void printperson(Person const &p)
    {
        cout << "Name    : " << p.name()     << "\n"
                "Address : " << p.address()  << "\n"
                "Phone   : " << p.phone()    << "\n"
                "Mass  : " << p.mass()   << '\n';
    }

    int main()
    {
        Person p;

        p.setName("Linus Torvalds");
        p.setAddress("E-mail: Torvalds@cs.helsinki.fi");
        p.setPhone(" - not sure - ");
        p.setMass(75);           // kg.

        printperson(p);
    }
/*
    Produced output:

Name    : Linus Torvalds
Address : E-mail: Torvalds@cs.helsinki.fi
Phone   :  - not sure -
Mass  : 75

*/

7.1.2: Constructors: with and without arguments

For the class Person a constructor expecting three strings and a size_t might be useful. Representing, respectively, the person's name, address, phone number and mass. This constructor is (but see also section 7.3.1):

    Person::Person(string const &name, string const &address,
                   string const &phone, size_t mass)
    {
        d_name = name;
        d_address = address;
        d_phone = phone;
        d_mass = mass;
    }

    class Person
    {
        // data members (not altered)

        public:
            Person(std::string const &name, std::string const &address,
                   std::string const &phone, size_t mass);

            // rest of the class interface (not altered)
    };

    class Person
    {
        // data members
        public:
            Person();
            Person(std::string const &name, std::string const &address,
                   std::string const &phone, size_t mass);

            // additional members
    };

• a random value for local Person objects;
• 0 for global and static Person objects.

    Person::Person()
    {
        d_mass = 0;
    }

    int main()
    {
        Person karel("Karel", "Rietveldlaan 37", "542 6044", 70);
        Person anon;
    }

If Person objects must be definable using other arguments, corresponding constructors must be added to Person's interface. Apart from overloading class constructors it is also possible to provide constructors with default argument values. These default arguments must be specified with the constructor declarations in the class interface, like so:

    class Person
    {
        public:
            Person(std::string const &name,
                   std::string const &address = "--unknown--",
                   std::string const &phone   = "--unknown--",
                   size_t mass = 0);

    };

Before the C++11 standard this situation was commonly handled like this: all constructors must initialize their reference and const data members, or the compiler (rightfully) complains. To initialize the remaining members (non-const and non-reference members) we have two options:

• If the body of the construction process is sizeable but (parameterizable) identical to other constructors bodies then factorize. Define a private member init which is called by the constructors to provide the object's data members with their appropriate values.
• If the constructors act fundamentally differently, then there's nothing to factorize and each constructor must be implemented by itself.

7.1.2.1: The order of construction

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

    class Test
    {
        public:
            Test(string const &name);   // constructor with an argument
    };

    Test::Test(string const &name)
    {
        cout << "Test object " << name << " created" << '\n';
    }

    Test globaltest("global");

    void func()
    {
        Test functest("func");
    }

    int main()
    {
        Test first("main first");
        func();
        Test second("main second");
    }
/*
    Generated output:
Test object global created
Test object main first created
Test object func created
Test object main second created
*/

7.2: Ambiguity resolution

    class Data
    {
        public:
            Data();
            Data(int one);
            Data(int one, int two);

            void display();
    };

The intention is to define two objects of the class Data, using, respectively, the first and second constructors. Your code looks like this (and compiles correctly):

    #include "data.h"
    int main()
    {
        Data d1();
        Data d2(argc);
    }

Now it's time to make some good use of the Data objects. You add two statements to main:

        d1.display();
        d2.display();

error: request for member 'display' in 'd1', which is of non-class type 'Data()'

What's going on here? First of all, notice the data type the compiler refers to: Data(), rather than Data. What are those () doing there?

Before answering that question, let's broaden our story somewhat. We know that somewhere in a library a factory function dataFactory exists. A factory function creates and returns an object of a certain type. This dataFactory function returns a Data object, constructed using Data's default constructor. Hence, dataFactory needs no arguments. We want to use dataFactory in our program, but must declare the function. So we add the declaration to main, as that's the only location where dataFactory will be used. It's a function, not requiring arguments, returning a Data object:

        Data dataFactory();

        Data d1();

We found the source of our problem: Data d1() apparently is not the definition of a d1 object, but the declaration of a function, returning a Data object. So, what's happening here and how should we define a Data object using Data's default constructor?

First: what's happening here is that the compiler, when confronted with Data d1(), actually had a choice. It could either define a Data object, or declare a function. It declares a function.

In fact, we're encountering an ambiguity in C++'s syntax here, which is solved, according to the language's standard, by always letting a declaration prevail over a definition. We'll encounter more situations where this ambiguity occurs later on in this section.

Second: there are several ways we can solve this ambiguity the way we want it to be solved. To define an object using its default constructor:

• merely mention it (like int x): Data d1;
• use the curly-brace initialization: Data d1{};
• use the assignment operator and an anonymous default constructed Data object: Data d1 = Data().

7.2.1: Types `Data' vs. `Data()'

Let's first have a look at our second constructor. It expects an int. We would like to define another Data object, using the second constructor, but want to pass the default int value to the constructor, using int(). We know this defines a default int value, as cout << int() << '\n' nicely displays 0, and int x = int() also initialized x to 0. So we define `Data di(int())' in main.

Not good: again the compiler complains when we try to use di. After `di.display()' the compiler tells us:

error: request for member 'display' in 'di', which is of non-class type 'Data(int (*)())'

Oops, not as expected.... Didn't we pass 0? Why the sudden pointer? It's that same `use a declaration when possible' strategy again. The notation Type() not only represents the default value of type Type, but it's also a shorthand notation for an anonymous pointer to a function, not expecting arguments, and returning a Type value, which you can verify by defining `int (*ip)() = nullptr', and passing ip as argument to di: di(ip) compiles fine.

So why doesn't the error occur when inserting int() or assigning int() to int x? In these latter cases nothing is declared. Rather, cout and int x = need expressions determining values, which is provided by int()'s `natural' interpretation. But with `Data di(int())' the compiler again has a choice, and (by design) it chooses a declaration because the declaration takes priority. Now int()'s interpretation as an anonymous pointer is available and therefore used.

Likewise, if int x has been defined, `Data b1(int(x))' declares b1 as a function, expecting an int (as int(x) represents a type), while `Data b2((int)x)' defines b2 as a Data object, using the constructor expecting a single int value.

7.2.2: Superfluous parentheses

    int b = 18;
    {
        Data(b);
        cout << b;
    }

error: cannot bind `std::ostream & << Data const &'

Here we didn't insert int b but Data b. Had we omitted the compound statement, the compiler would have complained about a doubly defined b entity, as Data(b) simply means Data b, a Data object constructed by default. The compiler may omit superfluous parentheses when parsing a definition or declaration.

Of course, the question now becomes how a temporary object Data, initialized with int b can be defined. Remember that the compiler may remove superfluous parentheses. So, what we need to do is to pass an int to the anonymous Data object, without using the int's name.

• We can use a cast: Data(static_cast<int>(b));
• We can use a curly-brace initialization: Data {b}.

Values and types make big differences. Consider the following definitions:

    Data (*d4)(int);    // 1
    Data (*d5)(3);      // 2

Definition 2 is slightly more complex. Yes, it's a pointer. But it has nothing to do with a function. So what's that argument list containing 3 doing there? Well, it's not an argument list. It's an initialization that looks like an argument list. Remember that variables can be initialized using the assignment statement, by parentheses or by curly parentheses. So instead of `(3)' we could have written `= 3' or `{3}'. Let's pick the first alternative, resulting in:

    Data (*d5) = 3;

    Data *d5 = 3;

     Data (*d5)(&d1);      // 2

7.2.3: Existing types

Assume a function process expecting an int exists in a library. We want to use this function to process some int data values. So in main process is declared and called:

    int process(int Data);
    process(argc);

    int process(int (Data));
    process(argc);

Here is another example. When, instead of declaring

    int process(int Data[10]);

    int process(int (Data[10]));

To summarize the findings in the `Ambiguity Resolution' section:

• The compiler will try to remove superfluous parentheses;
• But if the parenthesized construction represents a type, it will try to use the type;
• More in general: when possible the compiler will interpret a syntactic construction as a declaration, rather than as a definition (of an object or variable).

7.3: Objects inside objects: composition

Composition is neither extraordinary nor C++ specific: in C a struct or union field is commonly used in other compound types. In C++ it requires some special thought as their initialization sometimes is subject to restrictions, as discussed in the next few sections.

7.3.1: Composition and const objects: const member initializers

Earlier we've encountered the following constructor of the Person:

    Person::Person(string const &name, string const &address,
                   string const &phone, size_t mass)
    {
        d_name = name;
        d_address = address;
        d_phone = phone;
        d_mass = mass;
    }

The body of a constructor allows assignments to data members. The initialization of data members happens before that. C++ defines the member initializer syntax allowing us to specify the way data members are initialized at construction time. Member initializers are specified as a list of constructor specifications between a colon following a constructor's parameter list and the opening curly brace of a constructor's body, as follows:

    Person::Person(string const &name, string const &address,
                   string const &phone, size_t mass)
    :
        d_name(name),
        d_address(address),
        d_phone(phone),
        d_mass(mass)
    {}

Member initialization can, however, also be used for primitive data members, like int and double. The above example shows the initialization of the data member d_mass from the parameter mass. When member initializers are used the data member could even have the same name as the constructor's parameter (although this is deprecated) as there is no ambiguity and the first (left) identifier used in a member initializer is always a data member that is initialized whereas the identifier between parentheses is interpreted as the parameter.

The order in which class type data members are initialized is defined by the order in which those members are defined in the composing class interface. If the order of the initialization in the constructor differs from the order in the class interface, the compiler complains, and reorders the initialization so as to match the order of the class interface.

Member initializers should be used as often as possible. As shown it may be required to use them (e.g., to initialize const data members, or to initialize objects of classes lacking default constructors) but not using member initializers also results in inefficient code as the default constructor of a data member is always automatically called unless an explicit member initializer is specified. Reassignment in the constructor's body following default construction is then clearly inefficient. Of course, sometimes it is fine to use the default constructor, but in those cases the explicit member initializer can be omitted.

As a rule of thumb: if a value is assigned to a data member in the constructor's body then try to avoid that assignment in favor of using a member initializer.

7.3.2: Composition and reference objects: reference member initializers

A program uses an object of the class Configfile, defined in main to access the information in a configuration file. The configuration file contains parameters of the program which may be set by changing the values in the configuration file, rather than by supplying command line arguments.

Assume another object used in main is an object of the class Process, doing `all the work'. What possibilities do we have to tell the object of the class Process that an object of the class Configfile exists?

• The objects could have been declared as global objects. This is a possibility, but not a very good one, since all the advantages of local objects are lost.
• The Configfile object may be passed to the Process object at construction time. Bluntly passing an object (i.e., by value) might not be a very good idea, since the object must be copied into the Configfile parameter, and then a data member of the Process class can be used to make the Configfile object accessible throughout the Process class. This might involve yet another object-copying task, as in the following situation:

  Process::Process(Configfile conf)   // a copy from the caller
  {
      d_conf = conf;                  // copying to d_conf member
  }
  

• The copy-instructions can be avoided if pointers to the Configfile objects are used, as in:

  Process::Process(Configfile *conf)  // pointer to external object
  {
      d_conf = conf;                  // d_conf is a Configfile *
  }
  

  This construction as such is OK, but forces us to use the `->' field selector operator, rather than the `.' operator, which is (disputably) awkward. Conceptually one tends to think of the Configfile object as an object, and not as a pointer to an object. In C this would probably have been the preferred method, but in C++ we can do better.
• Rather than using value or pointer parameters, the Configfile parameter could be defined as a reference parameter of Process's constructor. Next, use a Config reference data member in the class Process.

    Process::Process(Configfile &conf)
    {
        d_conf = conf;        // wrong: no assignment
    }

How to initialize d_conf? We once again use the member initializer syntax. Here is the correct way to initialize d_conf:

    Process::Process(Configfile &conf)
    :
        d_conf(conf)      // initializing reference member
    {}

    Process::Process(int &ir)
    :
        d_ir(ir)
    {}

7.4: Data member initializers

Consider a class defining several data members: a pointer to data, a data member storing the number of data elements the pointer points at, a data member storing the sequence number of the object. The class also offer a basic set of constructors, as shown in the following class interface:

    class Container
    {
        Data *d_data;
        size_t d_size;
        size_t d_nr;

        static size_t s_nObjects;

        public:
            Container();
            Container(Container const &other);
            Container(Data *data, size_t size);
            Container(Container &&tmp);
    };

    Container()
    :
        d_data(0),
        d_size(0),
        d_nr(++s_nObjects)
    {}

C++, however, also supports data member initializers, simplifying the initialization of non-static data members. Data member initializers allow us to assign initial values to data members. The compiler must be able to compute these initial values from initialization expressions, but the initial values do not have to be constant expressions. So ++s_nObjects can be an initial value.

Using data member initializers for the class Container we get:

    class Container
    {
        Data *d_data = 0;
        size_t d_size = 0;
        size_t d_nr = ++nObjects;

        static size_t s_nObjects;

        public:
            Container() = default;
            Container(Container const &other);
            Container(Data *data, size_t size);
            Container(Container &&tmp);
    };

    Container(Container &&tmp)
    :
        d_data(tmp.d_data),
        d_size(tmp.d_size)
    {
        tmp.d_data = 0;
    }

An aggregate is an array or a class (usually a struct with no user-defined constructors, no private or protected non-static data members, no base classes (cf. chapter 13), and no virtual functions (cf. chapter 14)). E.g.,

    struct POD      // defining aggregate POD
    {
        int first = 5; 
        double second = 1.28; 
        std::string hello {"hello"};
    };

    POD pod {4, 13.5, "hi there"};

    POD pod {4};    // uses second: 1.28, hello: "hello"

7.4.1: Delegating constructors

Before the C++11 standard common practice was to define a member like init performing all initializations common to constructors. Such an init function, however, cannot be used to initialize const or reference data members, nor can it be used to perform so-called base class initializations (cf. chapter 13).

Here is an example where such an init function might have been used. A class Stat is designed as a wrapper class around C's stat(2) function. The class might define three constructors: one expecting no arguments and initializing all data members to appropriate values; a second one doing the same, but it calls stat for the filename provided to the constructor; and a third one expecting a filename and a search path for the provided file name. Instead of repeating the initialization code in each constructor, the common code can be factorized into a member init which is called by the constructors.

Currently, C++ offers an alternative by allowing constructors to call each other. This is called delegating constructors The C++11 standard allows us to delegate constructors as illustrated by the next example:

    class Stat
    {
        public:
            Stat()
            :
                State("", "")   // no filename/searchpath
            {}
            Stat(std::string const &fileName)
            :
                Stat(fileName, "")  // only a filename
            {}
            Stat(std::string const &fileName, std::string const &searchPath)
            :
                d_filename(fileName),
                d_searchPath(searchPath)
            {
                // remaining actions to be performed by the constructor
            }
    };

C++ allows static const integral data members to be initialized within the class interfaces (cf. chapter 8). The C++11 standard adds to this the facility to define default initializations for plain data members in class interfaces (these data members may or may not be const or of integral types, but (of course) they cannot be reference data members).

These default initializations may be overruled by constructors. E.g., if the class Stat uses a data member bool d_hasPath which is false by default but the third constructor (see above) should initialize it to true then the following approach is possible:

    class Stat
    {
        bool d_hasPath = false;

        public:
            Stat(std::string const &fileName, std::string const &searchPath)
            :
                d_hasPath(true)     // overrule the interface-specified
                                    // value
            {}
    };

7.5: Uniform initialization

C++ supports a comparable initialization, called uniform initialization. It uses the following syntax:

    Type object {value list};

The advantage of uniform initialization over using constructors is that using constructor arguments may sometimes result in an ambiguity as constructing an object may sometimes be confused with using the object's overloaded function call operator (cf. section 11.10). As initializer lists can only be used with plain old data (POD) types (cf. section 9.9) and with classes that are `initializer list aware' (like std::vector) the ambiguity does not arise when initializer lists are used.

Uniform initialization can be used to initialize an object or variable, but also to initialize data members in a constructor or implicitly in the return statement of functions. Examples:

    class Person
    {
        // data members
        public:
            Person(std::string const &name, size_t mass)
            :
                d_name {name},
                d_mass {mass}
            {}

            Person copy() const
            {
                return {d_name, d_mass};
            }
    };

Object definitions may be encountered in unexpected places, easily resulting in (human) confusion. Consider a function `func' and a very simple class Fun (struct is used, as data hiding is not an issue here; in-class implementatinos are used for brevity):

    void func();

    struct Fun
    {
        Fun(void (*f)())
        {
            std::cout << "Constructor\n";
        };

        void process()
        {
            std::cout << "process\n";
        }
    };

    Fun fun(func);
    Fun(func).process();

What about just defining an anonymous Fun object? We do:

    Fun(func);

So why does Fun(func).process() compile? In this case we have a member selector operator, whose left-hand operand must be an class-type object. The object must exist, and Fun(func) represents that object. It's not the name of an existing object, but a constructor expecting a function like func exists. The compiler now creates an anonymous Fun, passing it func as its argument.

Clearly, in this example, parentheses cannot be used to create an anonymous Fun object. However, the uniform initialization can be used. To define the anonymous Fun object use this syntax:

    Fun {func};

Although the uniform intialization syntax is slightly different from the syntax of an initializer list (the latter using the assignment operator) the compiler nevertheless uses the initializer list if a constructor supporting an initializer list is available. As an example consider:

    class Vector
    {
        public:
            Vector(size_t size);
            Vector(std::initializer_list<int> const &values);
    };

    Vector vi = {4};

Initializer lists are themselves objects that may be constructed using another initializer list. However, values stored in an initializer list are immutable. Once the initializer list has been defined their values remain as-is.

Before using the initializer_list the initializer_list header file must be included.

Initializer lists support a basic set of member functions and constructors:

• initializer_list<Type> object:

  defines object as an empty initializer list

• initializer_list<Type> object { list of Type values }:

  defines object as an initializer list containing Type values

• initializer_list<Type> object(other):

  initializes object using the values stored in other

• size_t size() const:

  returns the number of elements in the initializer list

• Type const *begin() const:

  returns a pointer to the first element of the initializer list

• Type const *end() const:

  returns a pointer just beyond the location of the last element of the initializer list

7.6: Defaulted and deleted class members

• A class offering constructors explicitly has to define a default constructor;
• A class (e.g., a class implementing a stream) cannot initialize objects by copying the values from an existing object of that class (called copy construction) and cannot assign objects to each other.

• Its data members of built-in or primitive types are not initialized;
• Its composed (class type) data members are initialized by their default constructors.
• If the class is derived from a base class (cf. chapter 13) the base class is initialized by its default constructor.

Conversely, situations exist where some (otherwise automatically provided) members should not be made available. This is realized by specifying `= delete'. Using = default and = delete is illustrated by the following example. The default constructor receives its trivial implementation, copy-construction is prevented:

    class Strings
    {
        public:
            Strings() = default;
            Strings(std::string const *sp, size_t size);

            Strings(Strings const &other) = delete;
    };

7.7: Const member functions and const objects

    class Person
    {
        public:
            std::string const &name()    const;
            std::string const &address() const;
            std::string const &phone()   const;
            size_t mass()              const;
    };

When implementing a const member function the const attribute must be repeated:

    string const &Person::name() const
    {
        return d_name;
    }

    d_name[0] = toupper(static_cast<unsigned char>(d_name[0]));

Const member functions are used to prevent inadvertent data modification. Except for constructors and the destructor (cf. chapter 9) only const member functions can be used with (plain, references or pointers to) const objects.

Const objects are frequently encounterd as const & parameters of functions. Inside such functions only the object's const members may be used. Here is an example:

    void displayMass(ostream &out, Person const &person)
    {
        out << person.name() << " weighs " << person.mass() << " kg.\n";
    }

The const member function attribute can be used to overload member functions. When functions are overloaded by their const attribute the compiler uses the member function matching most closely the const-qualification of the object:

• When the object is a const object, only const member functions can be used.
• When the object is not a const object, non-const member functions are used, unless only a const member function is available. In that case, the const member function is used.

    #include <iostream>
    using namespace std;

    class Members
    {
        public:
            Members();
            void member();
            void member() const;
    };

    Members::Members()
    {}
    void Members::member()
    {
        cout << "non const member\n";
    }
    void Members::member() const
    {
        cout << "const member\n";
    }

    int main()
    {
        Members const constObject;
        Members       nonConstObject;

        constObject.member();
        nonConstObject.member();
    }
    /*
            Generated output:

        const member
        non const member
    */

As a general principle of design: member functions should always be given the const attribute, unless they actually modify the object's data.

7.7.1: Anonymous objects

    class Print
    {
        public:
            Print(ostream &out);
            void print(std::string const &prefix, std::string const &text,
                     std::string const &suffix) const;
    };

    Print print(cout);
    for (int idx = 0; idx != argc; ++idx)
        print.print("arg: ", argv[idx], "\n");

    void allArgs(Print const &print, int argc, char *argv[])
    {
        for (int idx = 0; idx != argc; ++idx)
            print.print(argv[idx]);
    }

    Print(ostream &out, string const &prefix = "", string const &suffix = "");

    Print p1(cout, "arg: ", "\n");      // prints to cout
    Print p2(cerr, "err: --", "--\n");  // prints to cerr

    allArgs(p1, argc, argv);            // prints to cout
    allArgs(p2, argc, argv);            // prints to cerr

In such situations it is actually not necessary to define objects before they are used. Instead anonymous objects may be used. Anonymous objects can be used:

• to initialize a function parameter which is a const reference to an object;
• if the object is only used inside the function call.

Anonymous objects are defined when a constructor is used without providing a name for the constructed object. Here is the corresponding example:

    allArgs(Print(cout, "arg: ", "\n"), argc, argv);    // prints to cout
    allArgs(Print(cerr, "err: --", "--\n"), argc, argv);// prints to cerr

7.7.1.1: Subtleties with anonymous objects

    int main()
    {
        // initial statements
        Print("hello", "world");
        // later statements
    }

The example illustrates that the standard lifetime rules do not apply to anonymous objects. Their lifetimes are limited to the statements, rather than to the end of the block in which they are defined.

Plain anonymous object are at least useful in one situation. Assume we want to put markers in our code producing some output when the program's execution reaches a certain point. An object's constructor could be implemented so as to provide that marker-functionality allowing us to put markers in our code by defining anonymous, rather than named objects.

C++'s grammar contains another remarkable characteristic illustrated by the next example:

    int main(int argc, char **argv)
    {
        Print p(cout, "", "");              // 1
        allArgs(Print(p), argc, argv);      // 2
    }

In the above example a copy constructor is used to initialize an anonymous object. The anonymous object was then used to initialize a parameter of a function. However, when we try to apply the same trick (i.e., using an existing object to initialize an anonymous object) to a plain statement, the compiler generates an error: the object p can't be redefined (in statement 3, below):

    int main(int argc, char *argv[])
    {
        Print p("", "");                    // 1
        allArgs(Print(p), argc, argv);      // 2
        Print(p);                           // 3 error!
    }

The compiler actually provides us with the answer to this apparent contradiction. About statement 3 the compiler reports something like:

    error: redeclaration of 'Print p'

        Print (p);

        Print p;

As a further example: when we define a variable using a built-in type (e.g., double) using superfluous parentheses the compiler quietly removes these parentheses for us:

    double ((((a))));       // weird, but OK.

To summarize our findings about anonymous variables:

• Anonymous objects are great for initializing const reference parameters.
• The same syntaxis, however, can also be used in stand-alone statements, in which they are interpreted as variable definitions if our intention actually was to initialize an anonymous object using an existing object.
• Since this may cause confusion, it's probably best to restrict the use of anonymous objects to the first (and main) form: initializing function parameters.

7.8: Member function reference bindings (& and &&)

7.9: The keyword `inline'

    std::string const &Person::name() const
    {
        return d_name;
    }

    void showName(Person const &person)
    {
        cout << person.name();
    }

• The function Person::name() is called.
• This function returns person's d_name as a reference.
• The referenced name is inserted into cout.

7.9.1: Defining members inline

    class Person
    {
        public:
            std::string const &name() const
            {
                return d_name;
            }
    };

Although members can be defined in-class (i.e., inside the class interface itself), it is considered bad practice for the following reasons:

• Defining members inside the interface contaminates the interface with implementations. The interface's purpose is to document what functionality the class offers. Mixing member declarations and implementation details complicates understanding the interface. Readers need to skip implementation details which takes time and makes it hard to grab the `broad picture', and thus to understand at a glance what functionality the class's objects are offering.
• In-class implementations of private member functions may usually be avoided altogether (as they are private members). They should be moved to the internal header file (unless inline public members use such inline private members).
• Although members that are eligible for inline-coding should remain inline, situations do exist where such inline members migrate from an inline to a non-inline definition. In-class inline definitions still need editing (sometimes considerable editing) before they can be compiled. This additional editing is undesirable.

    class Person
    {
        public:
            std::string const &name() const;
    };

    inline std::string const &Person::name() const
    {
        return d_name;
    }

If it is ever necessary to cancel Person::name's inline implementation, then this becomes its non-inline implementation:

    #include "person.ih"

    std::string const &Person::name() const
    {
        return d_name;
    }

Defining members inline has the following effect: whenever an inline-defined function is called, the compiler may insert the function's body at the location of the function call. It may be that the function itself is never actually called.

This construction, where the function code itself is inserted rather than a call to the function, is called an inline function. Note that using inline functions may result in multiple occurrences of the code of those functions in a program: one copy for each invocation of the inline function. This is probably OK if the function is a small one, and needs to be executed fast. It's not so desirable if the code of the function is extensive. The compiler knows this too, and handles the use of inline functions as a request rather than a command. If the compiler considers the function too long, it will not grant the request. Instead it will treat the function as a normal function.

7.9.2: When to use inline functions

• In general inline functions should not be used. Voilà; that's simple, isn't it?
• Consider defining a function inline once a fully developed and tested program runs too slowly and shows `bottlenecks' in certain functions, and the bottleneck is removed by defining inline members. A profiler, which runs a program and determines where most of the time is spent, is necessary to perform such optimizations.
• Defining inline functions may be considered when they consist of one very simple statement (such as the return statement in the function Person::name).
• When a function is defined inline, its implementation is inserted in the code wherever the function is used. As a consequence, when the implementation of the inline function changes, all sources using the inline function must be recompiled. In practice that means that all functions must be recompiled that include (either directly or indirectly) the header file of the class in which the inline function is defined. Not a very attractive prospect.
• It is only useful to implement an inline function when the time spent during a function call is long compared to the time spent by the function's body. An example of an inline function which hardly affects the program's speed is:

  inline void Person::printname() const
  {
      cout << d_name << '\n';
  }
  

  This function contains only one statement. However, the statement takes a relatively long time to execute. In general, functions which perform input and output take lots of time. The effect of the conversion of this function printname() to inline would therefore lead to an insignificant gain in execution time.

7.9.2.1: A prelude: when NOT to use inline functions

There are situations where the compiler is confronted with so-called vague linkage
(cf. http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Vague-Linkage.html). These situations occur when the compiler does not have a clear indication in what object file to put its compiled code. This happens, e.g., with inline functions, which are usually encountered in multiple source files. Since the compiler may insert the code of ordinary inline functions in places where these functions are called, vague linking is usually no problem with these ordinary functions.

However, as explained in chapter 14, when using polymorphism the compiler must ignore the inline keyword and define so-called virtual members as true (out-of-line functions). In this situation the vague linkage may cause problems, as the compiler must decide in what object s to put their code. Usually that's not a big problem as long as the function is at least called once. But virtual functions are special in the sense that they may very well never be explicitly called. On some architectures (e.g., armel) the compiler may fail to compile such inline virtual functions. This may result in missing symbols in programs using them. To make matters slightly more complex: the problem may emerge when shared libraries are used, but not when static libraries are used.

To avoid all of these problems virtual functions should never be defined inline, but they should always be defined out-of-line. I.e., they should be defined in source files.

7.10: Local classes: classes inside functions

Local classes can be very useful in advanced applications involving inheritance or templates (cf. section 13.9). At this point in the C++ Annotations they have limited use, although their main features can be described. At the end of this section an example is provided.

• Local classes may use almost all characteristics of normal classes. They may have constructors, destructors, data members, and member functions;
• Local classes cannot define static data members. Static member functions, however, can be defined.
• Since a local class may define static member functions, it is possible to define nested functions in C++ somewhat comparable to the way programming languages like Pascal allow nested functions to be defined.
• If a local class needs access to a constant integral value, a local enum can be used. The enum may be anonymous, exposing only the enum values.
• Local classes cannot directly access the non-static variables of their surrounding context. For example, in the example shown below the class Local cannot directly access main's argc parameter.
• Local classes may directly access global data and static variables defined by their surrounding function. This includes variables defined in the anonymous namespace of the source file containing the local class.
• Local class objects can be defined inside the function body, but they cannot leave the function as objects of their own type. I.e., a local class name cannot be used for either the return type or for the parameter types of its surrounding function.
• As a prelude to inheritance (chapter 13): a local class may be derived from an existing class allowing the surrounding function to return a dynamically allocated locally constructed class object, pointer or reference could be returned via a base class pointer or reference.

#include <iostream>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
    static size_t staticValue = 0;

    class Local
    {
        int d_argc;             // non-static data members OK

        public:
            enum                // enums OK
            {
                VALUE = 5
            };
            Local(int argc)     // constructors and member functions OK
            :                   // in-class implementation required
                d_argc(argc)
            {
                                // global data: accessible
                cout << "Local constructor\n";
                                // static function variables: accessible
                staticValue += 5;
            }
            static void hello() // static member functions: OK
            {
                cout << "hello world\n";
            }
    };
    Local::hello();             // call Local static member
    Local loc(argc);            // define object of a local class.
}

7.11: The keyword `mutable'

C++ also allows the declaration of data members which may be modified, even by const member function. The declaration of such data members in the class interface start with the keyword mutable.

Mutable should be used for those data members that may be modified without logically changing the object, which might therefore still be considered a constant object.

An example of a situation where mutable is appropriately used is found in the implementation of a string class. Consider the std::string's c_str and data members. The actual data returned by the two members are identical, but c_str must ensure that the returned string is terminated by an 0-byte. As a string object has both a length and a capacity an easy way to implement c_str is to ensure that the string's capacity exceeds its length by at least one character. This invariant allows c_str to be implemented as follows:

    char const *string::c_str() const
    {
        d_data[d_length] = 0;
        return d_data;
    }

    mutable char *d_data;

The keyword mutable is also useful in classes implementing, e.g., reference counting. Consider a class implementing reference counting for textstrings. The object doing the reference counting might be a const object, but the class may define a copy constructor. Since const objects can't be modified, how would the copy constructor be able to increment the reference count? Here the mutable keyword may profitably be used, as it can be incremented and decremented, even though its object is a const object.

The keyword mutable should sparingly be used. Data modified by const member functions should never logically modify the object, and it should be easy to demonstrate this. As a rule of thumb: do not use mutable unless there is a very clear reason (the object is logically not altered) for violating this rule.

7.12: Header file organization

First, source files. With the exception of the occasional classless function, source files contain the code of member functions of classes. here there are basically two approaches:

• All required header files for a member function are included in each individual source file.
• All required header files (for all member functions of a class) are included in a header file that is included by each of the source files defining class members.

The second alternative has the advantage of economy for the program developer: the header file of the class accumulates header files, so it tends to become more and more generally useful. It has the disadvantage that the compiler frequently has to process many header files which aren't actually used by the function to compile.

With computers running faster and faster (and compilers getting smarter and smarter) I think the second alternative is to be preferred over the first alternative. So, as a starting point source files of a particular class MyClass could be organized according to the following example:

    #include <myclass.h>

    int MyClass::aMemberFunction()
    {}

The organization of the header file itself requires some attention. Consider the following example, in which two classes File and String are used.

Assume the File class has a member gets(String &destination), while the class String has a member function getLine(File &file). The (partial) header file for the class String is then:

    #ifndef STRING_H_
    #define STRING_H_

    #include <project/file.h>   // to know about a File

    class String
    {
        public:
            void getLine(File &file);
    };
    #endif

    #ifndef FILE_H_
    #define FILE_H_

    #include <project/string.h>   // to know about a String

    class File
    {
        public:
            void gets(String &string);
    };
    #endif

• The header file project/file.h is opened to be read;
• FILE_H_ is defined
• The header file project/string.h is opened to be read
• STRING_H_ is defined
• The header file project/file.h is (again) opened to be read
• Apparently, FILE_H_ is already defined, so the remainder of project/file.h is skipped.
• The interface of the class String is now parsed.
• In the class interface a reference to a File object is encountered.
• As the class File hasn't been parsed yet, a File is still an undefined type, and the compiler quits with an error.

    #ifndef STRING_H_
    #define STRING_H_

    class File;                 // forward reference

    class String
    {
        public:
            void getLine(File &file);
    };

    #include <project/file.h>   // to know about a File

    #endif

    #ifndef FILE_H_
    #define FILE_H_

    class String;               // forward reference

    class File
    {
        public:
            void gets(String &string);
    };

    #include <project/string.h>   // to know about a String

    #endif

This setup doesn't work with composition, nor with in-class inline member functions. Assume the class File has a composed data member of the class String. In that case, the class interface of the class File must include the header file of the class String before the class interface itself, because otherwise the compiler can't tell how big a File object is. A File object contains a String member, but the compiler can't determine the size of that String data member and thus, by implication, it can't determine the size of a File object.

In cases where classes contain composed objects (or are derived from other classes, see chapter 13) the header files of the classes of the composed objects must have been read before the class interface itself. In such a case the class File might be defined as follows:

    #ifndef FILE_H_
    #define FILE_H_

    #include <project/string.h>     // to know about a String

    class File
    {
        String d_line;              // composition !

        public:
            void gets(String &string);
    };
    #endif

All remaining header files (appearing below the class interface itself) are required only because they are used by the class's source files.

This approach allows us to introduce yet another refinement:

• Header files defining a class interface should declare what can be declared before defining the class interface itself. So, classes that are mentioned in a class interface should be specified using forward declarations unless
  • They are a base class of the current class (see chapter 13);
  • They are the class types of composed data members;
  • They are used in inline member functions.
  In particular: additional actual header files are not required for:
  • class-type return values of functions;
  • class-type value parameters of functions.
  Class header files of objects that are either composed or inherited or that are used in inline functions, must be known to the compiler before the interface of the current class starts. The information in the header file itself is protected by the #ifndef ... #endif construction introduced in section 2.5.10.
• Program sources in which the class is used only need to include this header file. Lakos, (2001) refines this process even further. See his book Large-Scale C++ Software Design for further details. This header file should be made available in a well-known location, such as a directory or subdirectory of the standard INCLUDE path.
• To implement member functions the class's header file is required and usually additional header files (like the string header file) as well. The class header file itself as well as these additional header files should be included in a separate internal header file (for which the extension .ih (`internal header') is suggested).

  The .ih file should be defined in the same directory as the source files of the class. It has the following characteristics:

  • There is no need for a protective #ifndef .. #endif shield, as the header file is never included by other header files.
  • The standard .h header file defining the class interface is included.
  • The header files of all classes used as forward references in the standard .h header file are included.
  • Finally, all other header files that are required in the source files of the class are included.
  An example of such a header file organization is:
  • First part, e.g., /usr/local/include/myheaders/file.h:

    #ifndef FILE_H_
    #define FILE_H_
    
    #include <fstream>      // for composed 'ifstream'
    
    class Buffer;           // forward reference
    
    class File              // class interface
    {
        std::ifstream d_instream;
    
        public:
            void gets(Buffer &buffer);
    };
    #endif
    

  • Second part, e.g., ~/myproject/file/file.ih, where all sources of the class File are stored:

    #include <myheaders/file.h> // make the class File known
    
    #include <buffer.h>         // make Buffer known to File
    #include <string>           // used by members of the class
    #include <sys/stat.h>       // File.
    

7.12.1: Using namespaces in header files

For example, if in a namespace special an object Inserter cout is declared, then special::cout is of course a different object than std::cout. Now, if a class Flaw is constructed, in which the constructor expects a reference to a special::Inserter, then the class should be constructed as follows:

    class special::Inserter;

    class Flaw
    {
        public:
            Flaw(special::Inserter &ins);
    };

    using namespace special;

    class Inserter;
    class Flaw
    {
        public:
            Flaw(Inserter &ins);
    };

    #include <flaw.h>
    #include <iostream>

    using std::cout;

    int main()
    {
        cout << "starting\n";       // won't compile
    }

As a rule of thumb, header files intended for general use should not contain using declarations. This rule does not hold true for header files which are only included by the sources of a class: here the programmer is free to apply as many using declarations as desired, as these directives never reach other sources.

7.13: Sizeof applied to class data members

    class Data
    {
        std::string d_name;
        ...
    };

    sizeof(Data::d_name);

• Table of Contents
• Previous Chapter
• Next Chapter