• reconciling inconsistent statements
• improving the precision of the words
• adding missing features

• the AT&T C++ 2.1 Product Reference Manual (the PRM)
• the C standard

Most C++ programmers know the PRM as the Annotated C++ Reference Manual, or ARM (Ellis and Stroustrup 1990). The ARM includes the text of the PRM along with annotations and commentary that elaborate the language description, explain many language design decisions and suggest implementation techniques. However, AT&T (which holds the copyrights to both the PRM and the ARM) only granted the C++ committee the right to use the PRM, so the current draft of the standard does not include the annotations and commentary.

The committee's first decisions brought the Working Paper closer to the ARM. The ARM includes chapters on templates and exception handling. cfront 2.1 did not include these features, so the PRM, and hence the base document, only had empty place holders for those chapters. The committee added these chapters to the Working Paper during its first year, so for all practical purposes, it's fair to say that the ARM is the base document.

X3J16 selected the ANSI C Standard as its second base document in the hope of minimizing unnecessary differences between C++ and C. I think some of us on the committee expected that, whenever C++ and C share a feature, the C++ standard would use the same, or nearly the same, wording as the C Standard. But to date, the C++ draft still employs wording that is closer to the ARM, even when describing features from C.

By the way, the politically correct term for the C++ draft is not the "draft," but the "Working Paper." The Working Paper won't be a draft until the committee submits it for public review. The first public review is at least a year away.

• C Compatibility — This group compares the C++ Working Paper with the C Standard and makes recommendations for reconciling their differences.
• Core Language — This group resolves ambiguities and inconsistencies in the core features of the language as specified by the PRM. This group recently divided into smaller groups: the "hard" core group tackles the broader issues that take many meetings to resolve, and the "soft" core group addresses a numerous collection of smaller issues.
• Environments — This group focuses on requirements for the translation environment (including the preprocessor and linker) and the execution environment (including program startup, execution, and termination).
• Extensions — This group evaluates proposals to add new language features to C++. It makes recommendations for accepting some and provides rationale for rejecting others. (WG21+X3J16 considers templates and exceptions to be extensions.)
• Libraries — This group drafts the specification of standard library components, including iostreams and the C++ version of the Standard C library.
• Syntax — This group recommends refinements to the formal C++ grammar to make the language more precise and easier to parse.

• support for European translation environments
• wchar_t as a keyword and a distinct type
• operator overloading for enumeration types
• overloading of new and delete operators for arrays
• relaxed restrictions on the return types for virtual functions
• runtime type identification

I will briefly summarize these extensions here, and cover them in detail in future columns.

template <class T>
inline T abs(T x)
   {
   return x >= 0 ? x : -x;
   }

The template itself doesn't generate any object code. Rather, the translator instantiates (creates) an abs function for a particular parameter type the first time you call abs with an argument of that type. For instance, if you call abs(i) for int i, the translator creates a definition for abs(int) as if you had defined

inline int abs(int x)
   {
   return x >= 0 ? x : -x;
   }

inline float abs(float x)
   {
   return x >= 0 ? x : -x;
   }

p = new T;
if (p == 0)
   // you're out of memory

This need arose because C uses the US ASCII character set as its alphabet. ASCII is the US national variant of the ISO 646 standard character set. Some or all of the ASCII characters [] { } | ^ ~aren't available in non-US variants of ISO 646. Other national variants of ISO 646 replace some of these characters with native language characters, making C programs a bit harder to write and read.

The normative addendum to the C Standard corrects the problem by adding new spellings as alternates for tokens that use ASCII-specific characters. The new spellings only use characters from the invariant ISO 646 character set.

Defining wchar_t as a typedef poses a problem for C++. Members of the libraries group wanted to be able to overload functions with arguments of type wchar_t, such as

int foo(int);
int foo(wchar_t);

ostream &operator<< (ostream &os, char c);
ostream &operator<< (ostream &os, int i);
ostream &operator<< (ostream &os, wchar_t w);

int i;
wchar_t w;

cout << i;

cout << W;

typedef wchar_t int;

ostream &operator<<(ostream &os, int i);
ostream &operator<<(ostream &os, wchar_t w);

Thus, WG21+X3J16 made wchar_t a new keyword in C++ representing a distinct type. wchar_t is still represented the same way as one of the standard integral types (meaning it has the same size, alignment requirements, and "signedness" as one of the integral types), but it is now a distinct type for the purposes of overload resolution.

enum color { RED, WHITE, BLUE };
enum color c = 0;

int n = BLUE;

This change introduces a more serious incompatibility with C: the predefined arithmetic operators, most notably ++, no longer apply to enumerations. Therefore, a loop such as

for (c = RED; c <= BLUE; ++c)

c <= BLUE

WG21+X3J16 reduced the trauma of this incompatibility by extending C++ to permit overloading on enumerations. For example, you can write the for loop above by defining

inline color &operator++(color &c)
   {
   return c = color(c + 1);
   }

Both malloc and new allocate memory, but new also applies a constructor to the storage if the allocated object has a class type with a constructor. That is, if X is a class with a constructor

p = new X;

p = (X *)malloc(sizeof(X));

Each C++ environment provides a default implementation for the new and delete operators. However, if this general-purpose allocator isn't right for your application, you can write you own versions of new and delete. For example,

void *operator new(size_t n)
   {
   ...
   }

void operator delete(void *p)
   {
   ...
   }

C++ not only lets you replace the global dynamic memory allocator, but even lets you define a different allocator for each class. That is,

class Y
   {
public:
   void *operator new(size_t);
   void operator delete(void *p);
   ...
   };

q = new Y;

delete q;

The ARM states that, even for a class Y that defines its own operator new, allocating an array of Y objects always uses the global operator new. That is,

q = new Y[n];

delete [] q;

The committee recently extended C++ to provide a separate set of dynamic memory management functions for arrays of objects:

void *operator new[](size_t n);
void operator delete[](void *p);

p : new X[m];

delete [] p;

You can even define operators new[] and delete[] for an individual class, such as

class Y
   {
public:
   void *operator new(size_t);
   void *operator new[] (size_t);
   void operator delete(void *p);
   void operator delete[](void *p);
   ...
   };

q = new Y[n];

• relaxing restrictions on the return types for virtual functions
• adding runtime type identification

Reference