Forgetting to write a special member function is a known programming problem.
Some authors recommend always defining all special member functions.
Such classes are less efficient.
First, these definitions may prevent the compiler
from passing the class in a register.
Second, these definitions may prevent the compiler
from using more efficient methods for copying.
Adding a comment that the default is intended
preserves the performance while ensuring that
the function was not forgotten.

Classes generally are either value classes or identity classes.
Copy constructors and assignment operators are fine for value classes.
They are often not appropriate to identity classes.
These classes should delete, or disable, these functions.
Marking such functions as follows
will enable compiling against C++03,
and later modifying them for C++11.

Multiple inheritance is confusing and rarely useful.
When it is needed though, there may be no substitute.
Seek guidance, review and feedback from the wider community.

Using virtual functions increases the size of instances of the class
by at least one pointer.
In heavily allocated types, such as trees, GIMPLE or RTL,
this size increase could have adverse performance impacts.
On the other hand,
virtual functions can often reduce the size of instances
by binding information into the virtual tables and the virtual functions.
For example, various type tags need not be present.
Other attributes can be inferred
from type and more general information,
or from extending the class hierarchy at the leaves.
So, even though trees are heavily allocated,
it remains to be seen whether virtual functions would increase the size.
Virtual functions are implemented as indirect function calls,
which can inhibit some optimization,
particularly inlining.
Therefore virtual functions should be added in heavily allocated classes
only after size and performance studies.
However, virtual functions are acceptable where we use hooks today,
as they are already essentially virtual tables.

There are good reasons to make private
all data members of non-POD classes.
However, in converting from C to C++,
there is a necessary transition that has public data members.

results in an unintended call to the int overload on some systems.
In practice, the problem that this restriction addresses
arises more from bad user-defined implicit conversion operators.
See ISO C++
N2437
and
ISO C++
N2514.

You may overload if a single argument, in a single position,
has multiple representations. For example,

void append (const char *str);
void append (std::string str);

You may not overload
if more than one argument constitutes the representation of some data notion.
For example, in

void register (int house, const char *street, int zipcode);

the arguments are a representation of addresses.
Instead, the overload should be on addresses.

void register(const Address &addr);

This restriction cannot apply to constructors,
where the whole point is to collect representational data.

Address::Address (int house, const char *street, int zipcode);

Notwithstanding the restrictions above, you may overload to detect errors.
That is, if unsigned numbers are good, but signed numbers are bad,
you could overload

void munch (unsigned int arg);
void munch (int arg);

and simply not define the signed int version.
Anyone using it would get a link-time error.
(The C++11 standard has a syntax
that enables compile-time detection of the problem.)

Default arguments cause confusion
when attempting to take the address of a function.
They clause client code taking the address of a function
to break when a default argument is replaced by a specialized overload.
So, default arguments should generally not be used
in customer-facing interfaces.
Consider function overloading instead.

Disabling exceptions will permit
the compiler itself to be slightly more optimized.

Aborting the compiler is a reasonable response to unexpected problems.

We would like the compiler to be exception safe,
to permit reconsideration of the exception convention.
This change would require a significant change in style,
adopting "resource acquisition is initialization" (RAII).
We would be using
shared_ptr (from TR1's <memory>)
or unique_ptr (from C++11).

Formatting Conventions

Prefixing data members with m_
highlights the extra overhead of access to fields over local variables.
Think of the leading m_ as being similar to the
* dereference operator.

When using the above convention,
the constructor parameter names
and getter member function names
can use the more concise non-underscore form.

For questions related to the use of GCC,
please consult these web pages and the
GCC manuals. If that fails,
the gcc-help@gcc.gnu.org
mailing list might help.
Comments on these web pages and the development of GCC are welcome on our
developer list at gcc@gcc.gnu.org.
All of our lists
have public archives.

Copyright (C)
Free Software Foundation, Inc.
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.