ec3.htm

一个非常适合初学者入门的有关c++的文档

{
  init();

  ...

}

ManyDataMbrs::ManyDataMbrs(const ManyDataMbrs& x)
{
  init();

  ...

}


Because the initialization routine is an implementation detail of the class, you are, of course, careful to make it private, right?
Note that static class members should never be initialized in a class's constructor. Static members are initialized only once per program run, so it makes no sense to try to "initialize" them each time an object of the class's type is created. At the very least, doing so would be inefficient: why pay to "initialize" an object multiple times? Besides, initialization of static class members is different enough from initialization of their nonstatic counterparts that an entire Item Item 47 is devoted to the topic. Back to Item 12: Prefer initialization to assignment in constructors.
Continue to Item 14: Make sure base classes have virtual destructors.
Item 13: List members in an initialization list in the order in which they are declared.
Unrepentant Pascal and Ada programmers often yearn for the ability to define arrays with arbitrary bounds, i.e., from 10 to 20 instead of from 0 to 10. Long-time C programmers will insist that everybody who's anybody will always start counting from 0, but it's easy enough to placate the begin/end crowd. All you have to do is define your own Array class template: template<class T>
class Array {
public:
  Array(int lowBound, int highBound);
  ...

private:
  vector<T> data;               // the array data is stored
                                // in a vector object; see
                                // Item 49 for info about
                                // the vector template


  size_t size;                  // # of elements in array


  int lBound, hBound;           // lower bound,higher bound
};

template<class T>
Array<T>::Array(int lowBound, int highBound)
:  size(highBound - lowBound + 1),
  lBound(lowBound),   hBound(highBound),
  data(size)
{}



An industrial-strength constructor would perform sanity checking on its parameters to ensure that highBound was at least as great as lowBound, but there is a much nastier error here: even with perfectly good values for the array's bounds, you have absolutely no idea how many elements data holds.
"How can that be?" I hear you cry. "I carefully initialized size before passing it to the vector constructor!" Unfortunately, you didn't you just tried to. The rules of the game are that class members are initialized in the order of their declaration in the class; the order in which they are listed in a member initialization list makes not a whit of difference. In the classes generated by your Array template, data will always be initialized first, followed by size, lBound, and hBound. Always.
Perverse though this may seem, there is a reason for it. Consider this scenario: class Wacko {
public:
  Wacko(const char *s): s1(s), s2(0) {}
  Wacko(const Wacko& rhs): s2(rhs.s1), s1(0) {}

private:
  string s1, s2;
};

Wacko w1 = "Hello world!";
Wacko w2 = w1;


If members were initialized in the order of their appearance in an initialization list, the data members of w1 and w2 would be constructed in different orders. Recall that the destructors for the members of an object are always called in the inverse order of their constructors. Thus, if the above were allowed, compilers would have to keep track of the order in which the members were initialized for each object, just to ensure that the destructors would be called in the right order. That would be an expensive proposition. To avoid that overhead, the order of construction and destruction is the same for all objects of a given type, and the order of members in an initialization list is ignored.
Actually, if you really want to get picky about it, only nonstatic data members are initialized according to the rule. Static data members act like global and namespace objects, so they are initialized only once; see Item 47 for details. Furthermore, base class data members are initialized before derived class data members, so if you're using inheritance, you should list base class initializers at the very beginning of your member initialization lists. (If you're using multiple inheritance, your base classes will be initialized in the order in which you inherit from them; the order in which they're listed in your member initialization lists will again be ignored. However, if you're using multiple inheritance, you've probably got more important things to worry about. If you don't, Item 43 would be happy to make suggestions regarding aspects of multiple inheritance that are worrisome.)
The bottom line is this: if you hope to understand what is really going on when your objects are initialized, be sure to list the members in an initialization list in the order in which those members are declared in the class. Back to Item 13: List members in an initialization list in the order in which they are declared.
Continue to Item 15: Have operator= return a reference to *this.
Item 14: Make sure base classes have virtual destructors.
Sometimes it's convenient for a class to keep track of how many objects of its type exist. The straightforward way to do this is to create a static class member for counting the objects. The member is initialized to 0, is incremented in the class constructors, and is decremented in the class destructor. (Item M26 shows how to package this approach so it's easy to add to any class, and my article on counting objects describes additional refinements to the technique.)
You might envision a military application, in which a class representing enemy targets might look something like this: class EnemyTarget {
public:
  EnemyTarget() { ++numTargets; }
  EnemyTarget(const EnemyTarget&) { ++numTargets; }
  ~EnemyTarget() { --numTargets; }

  static size_t numberOfTargets()
  { return numTargets; }


  virtual bool destroy();                 // returns success of
                                          // attempt to destroy
                                          // EnemyTarget object

private:
  static size_t numTargets;               // object counter
};

// class statics must be defined outside the class;
// initialization is to 0 by default
size_t EnemyTarget::numTargets;


This class is unlikely to win you a government defense contract, but it will suffice for our purposes here, which are substantially less demanding than are those of the Department of Defense. Or so we may hope.
Let us suppose that a particular kind of enemy target is an enemy tank, which you model, naturally enough (see Item 35, but also see Item M33), as a publicly derived class of EnemyTarget. Because you are interested in the total number of enemy tanks as well as the total number of enemy targets, you'll pull the same trick with the derived class that you did with the base class: class EnemyTank: public EnemyTarget {
public:
  EnemyTank() { ++numTanks; }

  EnemyTank(const EnemyTank& rhs)
  : EnemyTarget(rhs)
  { ++numTanks; }

  ~EnemyTank() { --numTanks; }

  static size_t numberOfTanks()
  { return numTanks; }

  virtual bool destroy();

private:
  static size_t numTanks;         // object counter for tanks
};


Having now added this code to two different classes, you may be in a better position to appreciate Item M26's general solution to the problem.
Finally, let's assume that somewhere in your application, you dynamically create an EnemyTank object using new, which you later get rid of via delete: EnemyTarget *targetPtr = new EnemyTank;

...

delete targetPtr;


Everything you've done so far seems completely kosher. Both classes undo in the destructor what they did in the constructor, and there's certainly nothing wrong with your application, in which you were careful to use delete after you were done with the object you conjured up with new. Nevertheless, there is something very troubling here. Your program's behavior is undefined you have no way of knowing what will happen.
The C++ language standard is unusually clear on this topic. When you try to delete a derived class object through a base class pointer and the base class has a nonvirtual destructor (as EnemyTarget does), the results are undefined. That means compilers may generate code to do whatever they like: reformat your disk, send suggestive mail to your boss, fax source code to your competitors, whatever. (What often happens at runtime is that the derived class's destructor is never called. In this example, that would mean your count of EnemyTanks would not be adjusted when targetPtr was deleted. Your count of enemy tanks would thus be wrong, a rather disturbing prospect to combatants dependent on accurate battlefield information.)
To avoid this problem, you have only to make the EnemyTarget destructor virtual. Declaring the destructor virtual ensures well-defined behavior that does precisely what you want: both EnemyTank's and EnemyTarget's destructors will be called before the memory holding the object is deallocated.
Now, the EnemyTarget class contains a virtual function, which is generally the case with base classes. After all, the purpose of virtual functions is to allow customization of behavior in derived classes (see Item 36), so almost all base classes contain virtual functions.
If a class does not contain any virtual functions, that is often an indication that it is not meant to be used as a base class. When a class is not intended to be used as a base class, making the destructor virtual is usually a bad idea. Consider this example, based on a discussion in the ARM (see Item 50): // class for representing 2D points
class Point {
public:
  Point(short int xCoord, short int yCoord);
  ~Point();

private:
  short int x, y;
};


If a short int occupies 16 bits, a Point object can fit into a 32-bit register. Furthermore, a Point object can be passed as a 32-bit quantity to functions written in other languages such as C or FORTRAN. If Point's destructor is made virtual, however, the situation changes.
The implementation of virtual functions requires that objects carry around with them some additional information that can be used at runtime to determine which virtual functions should be invoked on the object. In most compilers, this extra information takes the form of a pointer called a vptr ("virtual table pointer"). The vptr points to an array of function pointers called a vtbl ("virtual table"); each class with virtual functions has an associated vtbl. When a virtual function is invoked on an object, the actual function called is determined by following the object's vptr to a vtbl and then looking up the appropriate function pointer in the vtbl.
The details of how virtual functions are implemented are unimportant (though, if you're curious, you can read about them in Item M24). What is important is that if the Point class contains a virtual function, objects of that type will implicitly double in size, from two 16-bit shorts to two 16-bit shorts plus a 32-bit vptr! No longer will Point objects fit in a 32-bit register. Furthermore, Point objects in C++ no longer look like the same structure declared in another language such as C, because their foreign language counterparts will lack the vptr. As a result, it is no longer possible to pass Points to and from functions written in other languages unless you explicitly compensate for the vptr, which is itself an implementation detail and hence unportable.
The bottom line is that gratuitously declaring all destructors virtual is just as wrong as never declaring them virtual. In fact, many people summarize the situation this way: declare a virtual destructor in a class if and only if that class contains at least one virtual function.
This is a good rule, one that works most of the time, but unfortunately, it is possible to get bitten by the nonvirtual destructor problem even in the absence of virtual functions. For example, Item 13 considers a class template for implementing arrays with client-defined bounds. Suppose you decide (in spite of the advice in Item M33) to write a template for derived classes representing named arrays, i.e., classes where every array has a name: 
template<class T>                // base class template
class Array {                    // (from Item 13)
public:
  Array(int lowBound, int highBound);
  ~Array();

private:
  vector<T> data;
  size_t size;
  int lBound, hBound;
};

template<class T>
class NamedArray: public Array<T> {
public:
  NamedArray(int lowBound, int highBound, const string& name);
  ...

private:
  string arrayName;
};


If anywhere in an application you somehow convert a pointer-to-NamedArray into a pointer-to-Array and you then use delete on the Array pointer, you are instantly transported to the realm of undefined behavior: NamedArray<int> *pna =
  new NamedArray<int>(10, 20, "Impending Doom");

Array<int> *pa;

...


pa = pna;                // NamedArray<int>* -> Array<int>*

...


delete pa;               // undefined! (Insert theme to
                         //Twilight Zone here); in practice,
                         // pa->arrayName will often be leaked,
                         // because the NamedArray part of
                         // *pa will never be destroyed


This situation can arise more frequently than you might imagine, because it's not uncommon to want to take an existing class that does something, Array in this case, and derive from it a class that does all the same things, plus more. NamedArray doesn't redefine any of the behavior of Array it inherits all its functions without change it just adds some additional capabilities. Yet the nonvirtual destructor problem persists. (As do others. See Item M33.)
Finally, it's worth mentioning that it can be convenient to declare pure virtual destructors in some classes. Recall that pure virtual functions result in abstract classes classes that can't be instantiated (i.e., you can't create objects of that type). Sometimes, however, you have a class that you'd like to be abstract, but you don't happen to have any functions that are pure virtual. What to do? Well, because an abstract class is intended to be used as a base class, and because a base class should have a virtual destructor, and because a pure virtual function yields an abstract class, the solution is simple: declare a pure virtual destructor in the class you want to be abstract.
Here's an example: 
class AWOV {                // AWOV = "Abstract w/o
                            // Virtuals"
public:
  virtual ~AWOV() = 0;      // declare pure virtual
                            // destructor
};