A nested class is simply a class that's defined as a member of another class (its enclosing class). Nested classes are handy for reducing the number of global entities in a program, and with that the potential for global name conflicts.

• Within a structure object, the non-bit-field members and the units in which bitfields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa.
• A pointer to a union object, suitably converted, points to each of its members (or if a member is a bit-field, then to the unit in which it resides), and vice versa.
• Two structures share a common initial sequence if corresponding members have compatible types (and for bit-fields, the same width) for a sequence of one or more initial members. If a union contains several structures that share a common initial sequence, and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them.

Thus, according to the ARM, the first member of a struct object might not be at the same address as the struct object itself. The C++ standards committees acknowledged that this poses a compatibility problem for programmers migrating their C code to C++. However, the committees agreed they couldn't extend these layout guarantees to all class objects without hamstringing C++ implementations.

The committees solved the problem by extending the C layout guarantees only to POD-structs and POD-unions. POD stands for "plain ol' data" and more or less means "something you could write in C." More precisely, the C++ draft defines PODs in terms of aggregates:

An aggregate is an array, or an object of a class with no user-declared constructors, no private or protected members, no base classes, and no virtual functions.

The draft defines POD-struct and POD-union as:

A POD-struct is an aggregate structure that contains neither references nor pointers to members. Similarly, a POD-union is an aggregate union that contains neither references nor pointers to members.

Thus, the layout rules in the current draft C++ Standard are nearly identical to the rules in the C Standard, at least when applied to any object you could also declare in C.

T a[MAX];

T a[(M + 1) * (N + 1)];

Both C and C++ require integral constant expressions in a few other contexts, namely, bit-field size specifiers, case statement labels, and enumerator definitions. C programmers typically define symbols representing constant values as macros, using definitions such as

#define MAX 99

enum { MAX = 99 };

The disadvantage of an enumeration constant is that it can have only integral type. Thus, for example,

enum { PI = 3.1415926 };

C++ also lets programmers define symbolic constants as const-qualified objects, such as

const int MAX = 99;

In C++

const double PI = 3.1415926;

Unfortunately, C++ as defined in the ARM has no syntax for defining const-qualified objects at class scope as compile-time constants. For example, if a class X has an array member, as in

class X
   {
   ...
private:
   T a[MAX];
   };

class X
   {
public:
   const int MAX = 99; // error
   ...
private:
   T a[MAX];
   };

X::X(int m) : MAX(m)
   {
   ...
   }

C++ programmers generally use enumerations to define compile-time constants in class scope, as in:

class X
   {
public:
   enum { MAX = 99 };
   ...
private:
   T a[MAX];
   };

class X
   {
public:
   enum { LO = 'a', HI = 'z' };
   ...
private:
   char table[LO - HI + 1];
   };

cout << X::LO;

Alternatively, you can declare LO and HI as static const members, as in:

class X
   {
public:
   static const char LO;
   static const char HI;
   void f();
   ...
};

const char X::LO = 'a';
const char X::HI = 'z';

cout << X::LO;

void X::f()
   {
   char table[HI - LO + 1];
   ...
   }

class X
   {
public:
   static const char LO;
   static const char HI;
   void f();
   ...
private:
   char table[HI - LO + 1];  // error
   };

To correct this problem, the committees extended C++ to allow initialization of static const data members inside class scope. For example:

struct X
   {
public:
   static const char LO = 'a';
   static const char HI = 'z';
   void f();
   ...
private:
   char table[HI - LO + 1];
   };

A static const member initialized in class scope must still be defined outside the class. For example,

const char X::LO;   // still need definition after class
const char X::HI;   // still need definition after class

Even though static const data members with initializers define compile-time constants, such members have external linkage (as do all other static data members) and linkers must allocate space for them. A program can take the address of or bind a reference to static const data members.

#include <iostream.h>

main()
   {
   cout << "hello, world\n";
   }

#include <iostream.h>
#include <stdlib.h>
main()
   {
   cout << "hello, world\n";
   exit(0);
   }

return rv;

exit(rv);

The committees decided to silence these warnings by adding the following sentence to the draft standard:

If control reaches the end of main without encountering a return statement, the effect is that of executing

     return 0;

const T x = { };

Some committee members argued that programmers sometimes create empty classes (classes without members) as stubs. Although you can initialize an object of empty type T using a declaration such as

const T x = T();

This minor enhancement seemed harmless enough, so the committee agreed to augment the grammar rule for initializer-clause from:

initializer-clause:
   assignment-expression
   { initializer-list,opt }

initializer-clause:
   assignment-expression
   { initializer-list ,opt }
   { }

int a[5] = { };     // now ok

Normally, a constructor that accepts one argument is also a user-defined conversion. For example, if class complex has a constructor complex(double), then any function with a formal parameter of type complex, such as

void f(complex);

f(1.0);

void g(const complex &)

For classes like complex (and many others), the implicit conversions provided by single-argument constructors are what you want. Sometimes they are not. For example, a class vector might provide a constructor vector(int) so that users can declare vectors of a specified size, such as:

vector v(10);     // ok

void f(const vector &);

f(10);            // surprise!

The keyword explicit is a function-specifier, like inline or virtual. It may only appear in the declaration of a constructor within a class declaration, as in:

class vector
   {
public:
   explicit vector(int); // ok
   ...
   };

The committee added the keyword typename to correct a very subtle problem in the rules for resolving names used in templates. In short, the problem is that when parsing a template definition, a compiler can't always tell which names designate types and which do not. The template author can use the keyword typename to give the compiler a little more help.

For example, given

template <class T>
class X
   {
   void f()
      {
      T::A *a;
      ...
      }
   };

T::A *a;

typename T::A *a;

References