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)	( (aSomeFunction(); }


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.