C++ Tips[ZT]
C++ Tips
C++ Tips
Sections
Intro
I. ABCs and Inheritance
II. Scope
III. CLASSES
IV. MISC
V. OVERLOADING
VI. PARAMETERS
VII. Constructors (more on classes)
VIII.EXCEPTIONS
IX. TEMPLATES (more on classes)
Intro
This is not a code guideline document. See the C++ Style Guide for guidelines.
This is more of a document to fuel questions while you design and code
with C++. In some cases the point is simply stated and probably comes
off as a rule. In reality, they are simply meant as rules of thumb.
One of the main problems in C++ (more so than C) is that C++ provides
many mechanisms in the language by which the same task can be achieved
through different policies. For example, C++ has the Polymorphism mechanism.
Some of the policies are templates, macros, inheritance, overloading,
(those are the static, compile-time ones), and virtual functions (the
run-time polymorphic policy). Hopefully the following will provide
enough fuel for questions to arrive at the best policy to use for a
particular design.
I. ABCs and Inheritance
-----------------------
1. Abstract Base Class (ABC) : Make ABC class constructor protected when
possible. Derived classes can have public constructor to override
this. The same is true for non-ABC classes as well.
2. Class Inheritance : Use protected keyword where ever possible, never use
public to expose data members so the inheriting classes have access
to them.
3. Multiple Inheritance and VBC's :The only drawback is the most derived
class must initialize the lowest base classes. This breaks
encapsulation. Most people view multiple inheritance as a bad
thing, but when used sparingly for parts of a design, there is
no problem with it.
4. Data in classes should be keep private as much as possible. Use a
member function if a client needs to access the data. If a member
function does not need to be seen by a client, make it private.
If the class might be inherited, then protected may be a good choice.
5. Private inheritance: Don't use it. Too many ambiguities when used with
run-time type identification. Use a private data member instead
or use public inheritance.
Example: class Foo: private Bar { ... } dont do
6. Inheritance & virtual overrides: Care must be taken in overriding
inherited functions. Sometimes functions are grouped together,
and all need to be overridden. The base class designer must make
this clear, if overriding one function requires multiple
functions to be overridden.
7. Inheritance & Get/Set functions: Typically functions that perform
Get/Set shouldn't be overridden unless they are used by
the derived class. Otherwise if the base class does direct
field manipulation, you usually can't override it correctly,
or it could be a maintenance nightmare.
Note: Get/Set functions as referred to above are merely meant as
abstractions. As a rule of thumb (thumb must be getting pretty
big by now), one should not create functions called Get or Set,
or flavors thereof. They tend to break the spirit of encapsulation.
Of course, there will be times to use them.
II. SCOPE
---------
1. Law of Demeter : Do not make references to classes in a class that are
not variables of the class, inherited by the class, or global.
This also applies to including header files.
Example:
class Foo{public: Go(){} };
class Bar{ Foo aFoo; public: Foo GetFoo(){return aFoo;} };
class Fubar{ public:
void Bad(){ Bar aBar; aBar.GetFoo().Go(); }
};
The method Bad() breaks encapsulation. It calls a method of a class
it probably does not need to know about. This will also affect
maintainability. If the Foo class changes, the changes may also
need to be done in the Fubar class.
The other side of the coin that must be looked at is do you
want a pass-through method in the Bar class that simply
calls the Go() method of the Foo class. Lots of silly simple
1 line member functions may not be desirable in all the classes.
What probably needs to be looked at to decide what road to take
is speed, or perhaps redesign the classes.
Beyond the Law of Demeter is Doug's rule of thumb: Don't
play hide and seek with data.
2. Scope: Another way to say the previous point is to keep scope
small. This will increase the lifetime of the code and keep it
maintainable and safe.
III. CLASSES
------------
1. Be explicit about the keywords, public, protected, and private in a class
interface. Try not to have multiple sections. In other words,
multiple private sections in the class interface. It is generally
a good idea to place the public section first because this is
what most people are looking for when they go to use a class.
2. Make classes as atomic as possible. Give them a clear purpose. Break
them into smaller classes if they become too complex. This may
also eliminate duplicate code.
3. Don't let the compiler generate the default constructor,destructor,
operator= and copy constructor. If the class is entirely value
based, this is probably fine, if not, for example, if the class
has a data member that is a pointer, the above will probably not
work. Note, the default copy constructor only does a memcpy
of the class, so all you copy is the pointer data. This may not
be sufficient for copying a class. Regardless, if you do want the
default ones, place them in the code, and leave them commented.
For example:
// Fubar(const Fubar&) use default copy constructor
4. If your class contains pointers, you should create the default constructor
destructor, operator=, and copy constructor.
5. Class Copy: If the class should never be copied, then place the copy
constructor in the private section and don't implement it.
The linker will catch this, and the program will fail to build.
This, although not graceful, is better than a malformed program.
6. Initialization: Perform all data member initialization in the constructor.
It's best not to leave uninitialized objects running around in
the system. Note, it is often more efficient using the
constructor initializer list, otherwise, the default constructor
would be called, and then you probably call member functions of
the object later in the constructor. For example:
class Foo{ Bar mung; Foo(int iCount) : mung(iCount) {} ... };
The variable mung is initialized once. But in the following:
class Foo{ Bar mung; Foo(int iCount){ mung = iCount; } ... };
mung's default constructor is called before the body of the
class Foo's constructor is entered. Then mung is set again -
this assumes that mung has an assignment operator. The net
effect is that mung is initialized twice.
7. Class Naming: There exists several ways to name classes that seem to
work well for certain groups or people. There is Hungarian notation
and the "Taligent's Guide to Designing Programs" that document some
of the more typical methods.
IV. MISC
--------
1. Implicit int: The 'implicit int' rule will go away in the next
C++ standard. So for a proto like: 'main()' you will have to
say 'int main()' in the future. Same for variables.
2. Preprocessor: Avoid it. Use const values in the class, or inline
functions instead of macros. This is not to say, never use any
#defines.
Main reason: #define MIN(a,b) ( (a
SomeFunction(); }
V. OVERLOADING
--------------
1. operator overloading: It's syntactic sugar. Don't add them if they
are not needed. This does NOT refer to the typical ones like
'=', '==', but ones like '()', '[]', '+'. It does not always
make sense to add two objects together.
2. Overloading: If a member function is conditionally executing code,
it may be a candidate for operator overloading, or just overloading.
3. Operator overloading and chaining: When designing an overloaded
operator, think about whether it needs to be chained. For example:
String cstr = "a" + "b" + "c";
The String class's operator returns a reference to the String class.
A partial implementation might be:
class String{ public:
String& operator+(const char *pcBuf){
// code to add the char* to the string
return *this;
}
...
};
VI. PARAMETERS
--------------
1. Argument Passing: The first choice is typically a const ref. The
const ref is basically an alias, and is easier to use than a
pointer. It creates the same amount of instruction code as passing
a pointer (for most cases). It's typically better than passing
by value, where an object constructor will be called (if its an
object). As a rule of thumb, you might want too give the following
a whirl:
IN const &
OUT & If the object has the support functs
INOUT *& Acts like a **.
So for an IN parameter, what the 'const &' says, is here is a
reference to it, but you cannot modify the object. But you can
call member functions that do not change the object ( member
functions defined as const). The OUT parameter is a parameter
that is passed to a function that will modify it. If the parameter
needs to be created, then the INOUT parameter of *& may be a
good choice.
2. Returning Ref: In functions that return a reference, remember not to
reference a temporary object and return it. For example:
String &Zippo(void){ .... return String();
What happens, is that the String() is a temporary object that
upon return goes out of scope and is destroyed. Thus, you
return a reference to a destroyed object. Unfortunately, the
program will probably work in most cases till it's shipped.
The ol' Heisenbug!
3. Ref vs Pointer: Here's another way to look at when to use references,
and when should to use pointers.
C programmers sometimes don't like references since the
reference semantics they provide isn't *explicit* in the caller's
code. After a bit of C++ experience, however, one quickly realizes
this "information hiding" is an asset rather than a liability. In
particular, reuse-centered OOP tends to migrate the level of
abstraction away from the language of the machine toward the
language of the problem. References are usually preferred over
ptrs whenever you don't need "re-seating". This usually means that
references are most useful in a class' public interface. References
then typically appear on the skin of an object, and pointers on the
inside. The exception to the above is where a function's parameter
or return value needs a "sentinel" reference. This is usually best
done by returning/taking a pointer, and giving the nil ptr (0) this
special significance (references should always alias *objects*, not
a dereferenced nil ptr).
VII. Constructors (more on classes)
-----------------------------------
1. Creating Constructors: These creatures should be simple. Try not to
do anything in them that may generate errors. Remember they
don't have return values. If it's necessary to allocate
memory or other complex things in the constructor, throw an exception
if possible as the first recourse. Else, the class will have to be
protected everywhere that may use something that may be in error.
It's generally not a pretty sight to see an error returned in the
constructor's signature.
2. Constructors: Another reason to keep them simple is in the case
of inheritance.
3. Destructors: It's responsibility is to release resources allocated
during the class's lifetime, not just from construction.
4. Member Initialization List: The constructor can have a comma separated
member initialization list. If a class contains value based classes
as data members, they can be initialized in the constructor. For
example:
class Foo{
String cstr1; // value based class called String
String cstr2; // value based class called String
public:
Foo(const char* pcStr1, const char*pcStr2):
cstr1(pcStr1), cstr2(pcStr2){}
};
With the variables cstr1, and cstr2 initialized in the constructor,
they are initialized only once. Else, if they were initialized in
the body of the constructor, they would first be initialized with
a default constructor, then again in the body.
VIII. EXCEPTIONS
----------------
1. Exceptions: Use exception hierarchies, possibly even derived from the
Standard C++ ones.
2. Exceptions: Throw exceptions by value and catch them by reference.
This way the exception handling mechanism cleans up anything
created on the heap. If you throw exceptions by pointer, the
catcher must know how to destroy them. This is probably not
a good coupling. Even so, any up casting may slice and dice the
object.
IX. TEMPLATES (more on classes)
-------------------------------
1. Templates: Before creating new ones, see if they are in RogueWave,
or part of the C++ Standard.
2. Templates: When creating them, try to filter out any code that
does not depend on the type, and place that into a base class.
Thus, the template class itself is only the necessary information
that depends on type. Good examples can be found in RogueWave.
Douglas J. Waters (best reached on the internet) Internet: [email protected] Phone: (781) 359-7220