declare all class members explicitly as public, protected, or private, in groups in that order.
2.3 data members
data members should use the naming convention m_name where name is a normal hungarian local variable name. this makes member function implementations easier to read (no confusion about member vs. local data), and allows the use of the same hungarian name for, e.g., parameters and members. see the example below.
data members should normally not be declared public because this usually defeats the purpose of the class abstraction. to efficiently export a data member, declare inline get and set member functions. this will get optimized into the same code as a public data member. for example:
class counter
{
public:
int citems() const { return m_citems; }
void setcitems(int citems) { m_citems = citems; }
private:
int m_citems;
};
summary:
data members use the naming convention m_name.
do not declare public data members. use inline accessor functions for performance.
2.4 virtual functions
virtual functions are used to allow derived classes to override a method in a base class by providing their own implementation in a way that always causes the most-derived version to be called whenever a method is called through an object pointer, even if that pointer is declared as a pointer to the base class. this is usually done to implement polymorphism, and that抯 when we抣l use them. for example, all com interface methods are virtual because you are always going for polymorphism via a standard interface.
unlike simple member functions, virtual functions incur some overhead due to need to call through the vtable. if a class contains at least one virtual function then the data size of each instantiated object will be 4 bytes larger than the combined size of the declared data in order to hold the vtable pointer. after the first virtual function, each additional one only adds another entry to the class vtable, which is static and per-class (nothing per object), so the main concern here is whether a class has any virtual functions at all. in addition to the memory overhead, there is the overhead to indirect a pointer twice before calling the function. this is fairly fast and compact in 32-bit code, but affects speed and size nevertheless. perhaps the worst part is that virtual functions cannot be inlined, so there will always be a function call, even when the work is trivial.
because they have overhead, you should not use virtual functions in a class unless you need to. however, make sure you do use them when it makes sense. in particular, if you have a base class which requires a destructor, then the destructor should definitely be virtual to allow derived classes to destruct any added members properly. if the destructor were not virtual, then in a context where polymorphism is being used (so the object pointer is declared as a pointer to the base class), the base class destructor will always get called, even for an object of a derived class that added data members and declared its own destructor in an attempt to free them. the derived class抯 destructor will only get called if the base class destructor is declared virtual. this scenario applies to many other kinds of methods that you will add to your classes. in fact, most of the methods in a base class might be this way if polymorphism is intended. this issues is discussed in more detail in the inheritance section below.
note that although virtual functions have a performance penalty over regular member functions, they are often the most efficient way to implement a concept such as polymorphism where the alternative would be large switch statements (not to mention the benefits of the object-oriented encapsulation).
summary:
use virtual functions to implement polymorphism.
virtual functions have overhead, so don抰 use them unless you really should.
a destructor in a base class should always be virtual if polymorphism is intended.
2.5 constructors
ah, constructors. every new c++ programmer抯 nightmare. this is one reason to try to minimize the use of constructors -- c programmers aren抰 used to them and will get confused. another reason is the infamous performance overhead of calling a function (unless it抯 inline) and doing work at possibly unexpected and/or redundant times.
however, using constructors can eliminate the dangers of uninitialized data and can also made the code simpler to read (if you抮e used to it). judicious use of destructors (see below) which match the constructors can also help prevent memory leaks and other resource management problems.
