Back to Introduction
Continue to Item 1: Prefer const and inline to #define.

Shifting from C to C++

Getting used to C++ takes a little while for everyone, but for grizzled C programmers, the process can be especially unnerving. Because C is effectively a subset of C++, all the old C tricks continue to work, but many of them are no longer appropriate. To C++ programmers, for example, a pointer to a pointer looks a little funny. Why, we wonder, wasn't a reference to a pointer used instead?

C is a fairly simple language. All it really offers is macros, pointers, structs, arrays, and functions. No matter what the problem is, the solution will always boil down to macros, pointers, structs, arrays, and functions. Not so in C++. The macros, pointers, structs, arrays and functions are still there, of course, but so are private and protected members, function overloading, default parameters, constructors and destructors, user-defined operators, inline functions, references, friends, templates, exceptions, namespaces, and more. The design space is much richer in C++ than it is in C: there are just a lot more options to consider.

When faced with such a variety of choices, many C programmers hunker down and hold tight to what they're used to. For the most part, that's no great sin, but some C habits run contrary to the spirit of C++. Those are the ones that have simply got to go.

Back to Shifting from C to C++
Continue to Item 2: Prefer `<iostream>` to `<stdio.h>`.

Item 1: Prefer `const` and `inline` to `#define`.

This Item might better be called "prefer the compiler to the preprocessor," because `#define` is often treated as if it's not part of the language per se. That's one of its problems. When you do something like this,

    #define ASPECT_RATIO 1.653

the symbolic name `ASPECT_RATIO` may never be seen by compilers; it may be removed by the preprocessor before the source code ever gets to a compiler. As a result, the name `ASPECT_RATIO` may not get entered into the symbol table. This can be confusing if you get an error during compilation involving the use of the constant, because the error message may refer to `1.653`, not `ASPECT_RATIO`. If `ASPECT_RATIO` was defined in a header file you didn't write, you'd then have no idea where that `1.653` came from, and you'd probably waste time tracking it down. This problem can also crop up in a symbolic debugger, because, again, the name you're programming with may not be in the symbol table.

The solution to this sorry scenario is simple and succinct. Instead of using a preprocessor macro, define a constant:

    const double ASPECT_RATIO = 1.653;

This approach works like a charm. There are two special cases worth mentioning, however.

First, things can get a bit tricky when defining constant pointers. Because constant definitions are typically put in header files (where many different source files will include them), it's important that the pointer be declared `const`, usually in addition to what the pointer points to. To define a constant `char*`-based string in a header file, for example, you have to write `const` twice:

    const char * const authorName = "Scott Meyers";

For a discussion of the meanings and uses of `const`, especially in conjunction with pointers, see Item 21.

Second, it's often convenient to define class-specific constants, and that calls for a slightly different tack. To limit the scope of a constant to a class, you must make it a member, and to ensure there's at most one copy of the constant, you must make it a static member:

    class GamePlayer {
    private:
      static const int NUM_TURNS = 5;    // constant declaration
      int scores[NUM_TURNS];             // use of constant
      ...
    };

There's a minor wrinkle, however, which is that what you see above is a declaration for `NUM_TURNS`, not a definition. You must still define static class members in an implementation file:

    const int GamePlayer::NUM_TURNS;      // mandatory definition;
                                          // goes in class impl. file

There's no need to lose sleep worrying about this detail. If you forget the definition, your linker should remind you.

Older compilers may not accept this syntax, because it used to be illegal to provide an initial value for a static class member at its point of declaration. Furthermore, in-class initialization is allowed only for integral types (e.g., `int`s, `bool`s, `char`s, etc.), and only for constants. In cases where the above syntax can't be used, you put the initial value at the point of definition:

    class EngineeringConstants {      // this goes in the class
    private:                          // header file

      static const double FUDGE_FACTOR;

      ...

    };

    // this goes in the class implementation file
    const double EngineeringConstants::FUDGE_FACTOR = 1.35;

This is all you need almost all the time. The only exception is when you need the value of a class constant during compilation of the class, such as in the declaration of the array `GamePlayer::scores` above (where compilers insist on knowing the size of the array during compilation). Then the accepted way to compensate for compilers that (incorrectly) forbid the in-class specification of initial values for integral class constants is to use what is affectionately known as "the enum hack." This technique takes advantage of the fact that the values of an enumerated type can be used where `int`s are expected, so `GamePlayer` could just as well have been defined like this:

    class GamePlayer {
    private:
      enum { NUM_TURNS = 5 };    // "the enum hack" — makes
                                 // NUM_TURNS a symbolic name
                                 // for 5

      int scores[NUM_TURNS];     // fine

    ...

    };

Unless you're dealing with compilers of primarily historical interest (i.e., those written before 1995), you shouldn't have to use the enum hack. Still, it's worth knowing what it looks like, because it's not uncommon to encounter it in code dating back to those early, simpler times.

Getting back to the preprocessor, another common (mis)use of the `#define` directive is using it to implement macros that look like functions but that don't incur the overhead of a function call. The canonical example is computing the maximum of two values:

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

This little number has so many drawbacks, just thinking about them is painful. You're better off playing in the freeway during rush hour.

Whenever you write a macro like this, you have to remember to parenthesize all the arguments when you write the macro body; otherwise you can run into trouble when somebody calls the macro with an expression. But even if you get that right, look at the weird things that can happen:

    int a = 5, b = 0;

    max(++a, b);         // a is incremented twice
    max(++a, b+10);      // a is incremented once

Here, what happens to `a` inside `max` depends on what it is being compared with!

Fortunately, you don't need to put up with this nonsense. You can get all the efficiency of a macro plus all the predictable behavior and type-safety of a regular function by using an inline function (see Item 33):

    inline int max(int a, int b) { return a > b ? a : b; }

Now this isn't quite the same as the macro above, because this version of `max` can only be called with `int`s, but a template fixes that problem quite nicely:

    template<class T>
    inline const T& max(const T& a, const T& b)
    { return a > b ? a : b; }

This template generates a whole family of functions, each of which takes two objects convertible to the same type and returns a reference to (a constant version of) the greater of the two objects. Because you don't know what the type `T` will be, you pass and return by reference for efficiency (see Item 22).

By the way, before you consider writing templates for commonly useful functions like `max`, check the standard library (see Item 49) to see if they already exist. In the case of `max`, you'll be pleasantly surprised to find that you can rest on others' laurels: `max` is part of the standard C++ library.

Given the availability of `const`s and `inline`s, your need for the preprocessor is reduced, but it's not completely eliminated. The day is far from near when you can abandon `#include`, and `#ifdef`/`#ifndef` continue to play important roles in controlling compilation. It's not yet time to retire the preprocessor, but you should definitely plan to start giving it longer and more frequent vacations.

Back to Item 1: Prefer`const` and `inline` to `#define`.
Continue to Item 3: Prefer `new` and `delete` to `malloc` and `free`.

Item 2: Prefer `<iostream>` to `<stdio.h>`.

Yes, they're portable. Yes, they're efficient. Yes, you already know how to use them. Yes, yes, yes. But venerated though they are, the fact of the matter is that `scanf` and `printf` and all their ilk could use some improvement. In particular, they're not type-safe and they're not extensible. Because type safety and extensibility are cornerstones of the C++ way of life, you might just as well resign yourself to them right now. Besides, the `printf`/`scanf` family of functions separate the variables to be read or written from the formatting information that controls the reads and writes, just like FORTRAN does. It's time to bid the 1950s a fond farewell.

Not surprisingly, these weaknesses of `printf`/`scanf` are the strengths of `operator>>` and `operator<<`.

    int i;
    Rational r;                           // r is a rational number

    ...

    cin >> i >> r;
    cout << i << r;

If this code is to compile, there must be functions `operator>>` and `operator<<` that can work with an object of type `Rational` (possibly via implicit type conversion — see Item M5). If these functions are missing, it's an error. (The versions for `int`s are standard.) Furthermore, compilers take care of figuring out which versions of the operators to call for different variables, so you needn't worry about specifying that the first object to be read or written is an `int` and the second is a `Rational`.

In addition, objects to be read are passed using the same syntactic form as are those to be written, so you don't have to remember silly rules like you do for `scanf`, where if you don't already have a pointer, you have to be sure to take an address, but if you've already got a pointer, you have to be sure not to take an address. Let C++ compilers take care of those details. They have nothing better to do, and you do have better things to do. Finally, note that built-in types like `int` are read and written in the same manner as user-defined types like `Rational`. Try that using `scanf` and `printf`!

Here's how you might write an output routine for a class representing rational numbers:

    class Rational {
    public:
      Rational(int numerator = 0, int denominator = 1);

      ...

    private:
      int n, d;    // numerator and denominator

    friend ostream& operator<<(ostream& s, const Rational& r);
    };

    ostream& operator<<(ostream& s, const Rational& r)
    {
      s << r.n << '/' << r.d;
      return s;
    }

This version of `operator<<` demonstrates some subtle (but important) points that are discussed elsewhere in this book. For example, `operator<<` is not a member function (Item 19 explains why), and the `Rational` object to be output is passed into `operator<<` as a reference-to-`const` rather than as an object (see Item 22). The corresponding input function, `operator>>`, would be declared and implemented in a similar manner.

Reluctant though I am to admit it, there are some situations in which it may make sense to fall back on the tried and true. First, some implementations of iostream operations are less efficient than the corresponding C stream operations, so it's possible (though unlikely — see Item M16) that you have an application in which this makes a significant difference. Bear in mind, though, that this says nothing about iostreams in general, only about particular implementations; see Item M23. Second, the iostream library was modified in some rather fundamental ways during the course of its standardization (see Item 49), so applications that must be maximally portable may discover that different vendors support different approximations to the standard. Finally, because the classes of the iostream library have constructors and the functions in `<stdio.h>` do not, there are rare occasions involving the initialization order of static objects (see Item 47) when the standard C library may be more useful simply because you know that you can always call it with impunity.

The type safety and extensibility offered by the classes and functions in the iostream library are more useful than you might initially imagine, so don't throw them away just because you're used to `<stdio.h>`. After all, even after the transition, you'll still have your memories.

Incidentally, that's no typo in the Item title; I really mean `<iostream>` and not `<iostream.h>`. Technically speaking, there is no such thing as `<iostream.h>` — the °standardization committee eliminated it in favor of `<iostream>` when they truncated the names of the other non-C standard header names. The reasons for their doing this are explained in Item 49, but what you really need to understand is that if (as is likely) your compilers support both `<iostream>` and `<iostream.h>`, the headers are subtly different. In particular, if you `#include` `<iostream>`, you get the elements of the iostream library ensconced within the namespace `std` (see Item 28), but if you `#include` `<iostream.h>`, you get those same elements at global scope. Getting them at global scope can lead to name conflicts, precisely the kinds of name conflicts the use of namespaces is designed to prevent. Besides, `<iostream>` is less to type than `<iostream.h>`. For many people, that's reason enough to prefer it.

Back to Item 2: Prefer `<iostream>` to `<stdio.h>`.
Continue to Item 4: Prefer C++-style comments.

Item 3: Prefer `new` and `delete` to `malloc` and `free`.

The problem with `malloc` and `free` (and their variants) is simple: they don't know about constructors and destructors.

Consider the following two ways to get space for an array of 10 `string` objects, one using `malloc`, the other using `new`:

    string *stringArray1 =
      static_cast<string*>(malloc(10 * sizeof(string)));

    string *stringArray2 = new string[10];

Here `stringArray1` points to enough memory for 10 `string` objects, but no objects have been constructed in that memory. Furthermore, without jumping through some rather obscure linguistic hoops (such as those described in Items M4 and M8), you have no way to initialize the objects in the array. In other words, `stringArray1` is pretty useless. In contrast, `stringArray2` points to an array of 10 fully constructed `string` objects, each of which can safely be used in any operation taking a `string`.

Nonetheless, let's suppose you magically managed to initialize the objects in the `stringArray1` array. Later on in your program, then, you'd expect to do this:

    free(stringArray1);

    delete [] stringArray2;      // see Item 5 for why the
                                 // "[]" is necessary

The call to `free` will release the memory pointed to by `stringArray1`, but no destructors will be called on the `string` objects in that memory. If the `string` objects themselves allocated memory, as `string` objects are wont to do, all the memory they allocated will be lost. On the other hand, when `delete` is called on `stringArray2`, a destructor is called for each object in the array before any memory is released.

Because `new` and `delete` interact properly with constructors and destructors, they are clearly the superior choice.

Mixing `new` and `delete` with `malloc` and `free` is usually a bad idea. When you try to call `free` on a pointer you got from `new` or call `delete` on a pointer you got from `malloc`, the results are undefined, and we all know what "undefined" means: it means it works during development, it works during testing, and it blows up in your most important customers' faces.

The incompatibility of `new`/`delete` and `malloc`/`free` can lead to some interesting complications. For example, the `strdup` function commonly found in `<string.h>` takes a `char*`-based string and returns a copy of it:

    char * strdup(const char *ps);      // return a copy of what
                                        // ps points to

At some sites, both C and C++ use the same version of `strdup`, so the memory allocated inside the function comes from `malloc`. As a result, unwitting C++ programmers calling `strdup` might overlook the fact that they must use `free` on the pointer returned from `strdup`. But wait! To forestall such complications, some sites might decide to rewrite `strdup` for C++ and have this rewritten version call `new` inside the function, thereby mandating that callers later use `delete`. As you can imagine, this can lead to some pretty nightmarish portability problems as code is shuttled back and forth between sites with different forms of `strdup`.

Still, C++ programmers are as interested in code reuse as C programmers, and it's a simple fact that there are lots of C libraries based on `malloc` and `free` containing code that is very much worth reusing. When taking advantage of such a library, it's likely you'll end up with the responsibility for `free`ing memory `malloc`ed by the library and/or `malloc`ing memory the library itself will `free`. That's fine. There's nothing wrong with calling `malloc` and `free` inside a C++ program as long as you make sure the pointers you get from `malloc` always meet their maker in `free` and the pointers you get from `new` eventually find their way to `delete`. The problems start when you get sloppy and try to mix `new` with `free` or `malloc` with `delete`. That's just asking for trouble.

Given that `malloc` and `free` are ignorant of constructors and destructors and that mixing `malloc`/`free` with `new`/`delete` can be more volatile than a fraternity rush party, you're best off sticking to an exclusive diet of `new`s and `delete`s whenever you can.

Back to Item 3: Prefer `new` and `delete` to `malloc` and `free`.
Continue to Memory Management

Item 4: Prefer C++-style comments.

The good old C comment syntax works in C++ too, but the newfangled C++ comment-to-end-of-line syntax has some distinct advantages. For example, consider this situation:

    if ( a > b ) {
      // int temp = a;    // swap a and b
      // a = b;
      // b = temp;
    }

Here you have a code block that has been commented out for some reason or other, but in a stunning display of software engineering, the programmer who originally wrote the code actually included a comment to indicate what was going on. When the C++ comment form was used to comment out the block, the embedded comment was of no concern, but there could have been a serious problem had everybody chosen to use C-style comments:

    if ( a > b ) {
      /*  int temp = a;  /* swap a and b */
          a = b;
          b = temp;
      */
    }

Notice how the embedded comment inadvertently puts a premature end to the comment that is supposed to comment out the code block.

C-style comments still have their place. For example, they're invaluable in header files that are processed by both C and C++ compilers. Still, if you can use C++-style comments, you are often better off doing so.

It's worth pointing out that retrograde preprocessors that were written only for C don't know how to cope with C++-style comments, so things like the following sometimes don't work as expected:

    #define LIGHT_SPEED   3e8    // m/sec (in a vacuum)

Given a preprocessor unfamiliar with C++, the comment at the end of the line becomes part of the macro! Of course, as is discussed in Item 1, you shouldn't be using the preprocessor to define constants anyway.

Back to Item 4: Prefer C++-style comments
Continue to Chapter 2: Memory Management