Ellemtel C++ Styel and Rules - Classes

You must know what you are doing if you invoke virtual functions from a constructor in the class. If virtual functions in a derived class are overridden, the original definition in the base class will still be invoked by the base class' constructor. Override, then, does not always work when invoking virtual functions in constructors. See Example 30.

Exception to Rule 25

Sometimes, it is desired to let objects in a class share a data area. In such a case, it is not necessary to define a copy constructor. Instead, it is necessary to make sure that this data area is not deallocated as long as there are pointers to it.

Exception to Rule 26

No exceptions.

   #include <string.h>

   class String
   {
      public:
         String( const char* cp = "");    // Constructor
         ~String();                       // Destructor
         // ...
      private:
         char* sp;
         // ...
   };

   String::String(const char* cp) : sp( new char[strlen(cp)] )     // Constructor
   {
      strcpy(sp,cp);
   }
   String::~String()    // Destructor
   {
      delete sp;
   }

   // "Dangerous" String class
   void
   main()
   {
      String w1;
      String w2 = w1;
      // WARNING: IN A BITWISE COPY OF w1::sp,
      // THE DESTRUCTOR FOR W1::SP WILL BE CALLED TWICE:
      // FIRST, WHEN w1 IS DESTROYED; AGAIN, WHEN w2 IS DESTROYED.
   }

   #include <string.h>

   class String
   {
      public:
         String( const char* cp = "");   // Constructor
         String( const String& sp );     // Copy constructor
         ~String();                      // Destructor
         // ...
      private:
         char* sp;
         // ...
   };

   String::String( const char* cp ) : sp( new char[strlen(cp)] )    // Constructor
   {
      strcpy(sp,cp);
   }

   String::String( const String& stringA ) : sp( new char[strlen(stringA.sp)] )
   {
      strcpy(sp,stringA.sp);
   }
   String::~String()     // Destructor
   {
      delete sp;
   }

   // "Safe" String class
   void
   main()
   {
      String w1;
      String w2 = w1;   // SAFE COPY: String::String( const String& ) CALLED.
   }

   class Fruit
   {
      public:
         ~Fruit();     // Forgot to make destructor virtual!!
         // ...
   };

   class Apple : public Fruit
   {
      public:
         ~Apple();     // Destructor
         // ...
   };

   // "Dangerous" usage of pointer to base class

   class FruitBasket
   {
      public:
         FruitBasket(); // Create FruitBasket
         ~FruitBasket();// Delete all fruits// ...
         void add(Fruit*); // Add instance allocated on the free store
         // ...
      private:
         Fruit* storage[42]; // Max 42 fruits stored
         int numberOfStoredFruits;
   };

   void
   FruitBasket::add(Fruit* fp)
   {
      // Store pointer to fruit
      storage[numberOfStoredFruits++] = fp;
   }

   FruitBasket::FruitBasket() : numberOfStoredFruits(0)
   {
   }

   FruitBasket::~FruitBasket()
   {
      while (numberOfStoredFruits > 0)
      {
         delete storage[--numberOfStoredFruits]; // Only Fruit::~Fruit is called !!
      }
   }

   // Hen.hh
   class Egg;

   class Hen
   {
      public:
         Hen();    // Default constructor
         ~Hen();   // Destructor// ...
         void makeNewHen(Egg*);
         // ...
   };

   // Egg.hh

   class Egg { };

   extern Egg theFirstEgg; // defined in Egg.cc

   // FirstHen.hh

   class FirstHen : public Hen
   {
      public:
         FirstHen();    // Default constructor
         // ...
   };

   extern FirstHen theFirstHen; // defined in FirstHen.cc

   // FirstHen.cc

   FirstHen theFirstHen; // FirstHen::FirstHen() called

   FirstHen::FirstHen()
   {
      // The constructor is risky because theFirstEgg is a global object
      // and may not yet exist when theFirstHen is initialized.
      // Which comes first, the chicken or the egg ?

      makeNewHen(&theFirstEgg);
   }

   // WARNING!!! THIS CODE IS NOT FOR BEGINNERS !!!

   // PortSetup.hh

   class PortSetup
   {
      public:
         PortSetup();// Constructor: initializes flag
         void foo();// Only works correctly if flag is 42
      private:
         int flag;// Always initialized to 42
   };

   extern PortSetup portSetup;  // Must be initialized before use

   // Create one instance of portSetupInit in each translation unit
   // The constructor for portSetupInit will be called once for each
   // translation unit. It initializes portSetup by using the placement
   // syntax for the "new" operator.

   static 
   class PortSetupInit
   {
      public:
         PortSetupInit();           // Default constructor
      private:
         static int isPortSetup;
   } portSetupInit;

   // PortSetup.cc

   #include "PortSetup.hh"
   #include <new.h>

   // ...

   PortSetupInit::PortSetupInit()   // Default constructor
   { 
      if (!isPortSetup) 
      {
         new (&portSetup) PortSetup; 
         isPortSetup = 1;
      }
   }

   class Base
   {
      public:
         Base();       // Default constructor
         virtual void foo() { cout << "Base::foo" << endl; }
   // ...
   };

   Base::Base()
   {
      foo();     // Base::foo() is ALWAYS called.
   }

   // Derived class overrides foo()
   class Derived : public Base
   {
      public:
         virtual void foo() { cout << "Derived::foo" << endl; } //foo is overridden
         // ...
   };

   main()
   {
      Derived d;  // Base::foo() called when the Base-part of
            // Derived is constructed.
   }

Rule 27

A class which uses "new" to allocate instances managed by the class, [i.e. instances bound to member variables of pointer or reference type that are deallocated by the object.] must define an assignment operator.

Rule 28

An assignment operator which performs a destructive action must be protected from performing this action on the object upon which it is operating.

Rec. 34

An assignment operator ought to return a const reference to the assigning object.

An assignment is not inherited like other operators. If an assignment operator is not explicitly defined, then one is automatically defined instead. Such an assignment operator does not perform bit-wise copying of member data; instead, the assignment operator (if defined) for each specific type of member data is invoked. Bit-wise copying is only performed for member data having primitive types.

One consequence of this is that bit-wise copying is performed for member data having pointer types. If an object manages the allocation of the instance of an object pointed to by a pointer member, this will probably lead to problems: either by invoking the destructor for the managed object more than once or by attempting to use the deallocated object. See also Rule 25.

If an assignment operator is overloaded, the programmer must make certain that the base class' and the members' assignment operators are run.

A common error is assigning an object to itself (a = a). Normally, destructors for instances which are allocated on the heap are invoked before assignment takes place. If an object is assigned to itself, the values of the instance variables will be lost before they are assigned. This may well lead to strange run-time errors. If a = a is detected, the assigned object should not be changed.

If an assignment operator returns "void", then it is not possible to write a = b = c. It may then be tempting to program the assignment operator so that it returns a reference to the assigning object. Unfortunately, this kind of design can be difficult to understand. The statement (a = b) = c can mean that a or b is assigned the value of c before or after a is assigned the value of b. This type of code can be avoided by having the assignment operator return a const reference to the assigned object or to the assigning object. Since the returned object cannot be placed on the left side of an assignment, it makes no difference which of them is returned (that is, the code in the above example is no longer correct).

Exception to Rule 27

Sometimes, it is desirable to allow objects in a class to share a data area. In such cases, it is not necessary to define an assignment operator. Instead, it is necessary to make sure that the shared data area is no deallocated as long as there are pointers to it.

Exception to Rule 28

No exceptions.

   void
   MySpecialClass::operator=( const MySpecialClass& msp );      / Well ...?

   MySpecialClass&
   MySpecialClass::operator=( const MySpecialClass& msp );      // No!

   const MySpecialClass&
   MySpecialClass::operator=( const MySpecialClass& msp );      // Recommended

   class DangerousBlob
   {
      public:
         const DangerousBlob& operator=( const DangerousBlob& dbr );
         // ...
      private:
         char* cp;
   };

   // Definition of assignment operator

   const DangerousBlob&
   DangerousBlob::operator=( const DangerousBlob& dbr )
   {
      if ( this != &dbr )    // Guard against assigning to the "this" pointer
      {
         delete cp;         // Disastrous if this == &dbr
      }
      // ...
   }

Rec. 35

Use operator overloading sparingly and in a uniform manner.

Rec. 36

When two operators are opposites (such as == and !=), it is appropriate to define both.

Operator overloading has both advantages and disadvantages. One advantage is that code which uses a class with overloaded operators can be written more compactly (more readably). Another advantage is that the semantics can be both simple and natural. One disadvantage in overloading operators is that it is easy to misunderstand the meaning of an overloaded operator (if the programmer has not used natural semantics). The extreme case, where the plus-operator is re-defined to mean minus and the minus-operator is re-defined to mean plus, probably will not occur very often, but more subtle cases are conceivable.

Designing a class library is like designing a language! If you use operator overloading, use it in a uniform manner; do not use it if it can easily give rise to misunderstanding.

If the operator != has been designed for a class, then a user may well be surprised if the operator == is not defined as well. 7.8. Member Function Return Types

Rule 29

A public member function must never return a non-const reference or pointer to member data.

Rule 30

A public member function must never return a non-const reference or pointer to data outside an object, unless the object shares the data with other objects.

By allowing a user direct access to the private member data of an object, this data may be changed in ways not intended by the class designer. This may lead to reduced confidence in the designer's code: a situation to be avoided.

A worse risk is having pointers which point to deallocated memory. Rule 29 and Rule 30 attempt to avoid this situation.

Note that we do not forbid the use of protected member functions which return a const reference or pointer to member data. If protected access functions are provided, the problems described in 7.1 are avoided.

Exception to Rule 29

No exceptions.

Exception to Rule 30

No exceptions.

   class Account
   {
      public:
         Account( int myMoney ) : moneyAmount( myMoney ) {};
         const int& getSafeMoney() const { return moneyAmount; }
         int& getRiskyMoney() const { return moneyAmount; }       // No!
         // ...
      private:
         int moneyAmount;
   };

   Account myAcc(10);   // I'm a poor lonesome programmer a long way from home

   myAcc.getSafeMoney() += 1000000;  // Compilation error: assignment to constant

   myAcc.getRiskyMoney() += 1000000; // myAcc::moneyAmount = 1000010 !!

Rec. 37

Avoid inheritance for parts-of relations.

Rec. 38

Give derived classes access to class type member data by declaring protected access functions.

A common mistake is to use multiple inheritance for parts-of relations (when an object consists of several other objects, these are inherited instead of using instance variables. This can result in strange class hierarchies and less flexible code. In C++ there may be an arbitrary number of instances of a given type; if inheritance is used, direct inheritance from a class may only be used once. [As opposed to the language Eiffel, in which multiple, repeated inheritance is permitted.]

A derived class often requires access to base class member data in order to create useful member functions. The advantage in using protected member functions is that the names of base class member data are not visible in the derived classes and thus may be changed. Such access functions should only return the values of member data (read-only access). This is best done by simply invoking const functions for the member data.

The guiding assumption is that those who use inheritance know enough about the base class to be able to use the private member data correctly, while not referring to this data by name. This reduces the coupling between base classes and derived classes.