Stepping Up To C++

Stepping Up To C++

Minor Enhancements to C++ as of CD Registration

Dan Saks

Dan Saks is the president of Saks & Associates, which offers consulting and training in C++ and C. He is secretary of the ANSI and ISO C++ committees. Dan is coauthor of C++ Programming Guidelines, and codeveloper of the Plum Hall Validation Suite for C++ (both with Thomas Plum). You can reach him at 393 Leander Dr., Springfield OH, 45504-4906, by phone at (513)324-3601, or electronically at [email protected].

In July, the ANSI and ISO C++ standards committees voted to submit their working draft of the C++ standard for registration as a CD (committee draft). This is the second installment in a series that summarizes the state of the C++ language as of that milestone.

Since adopting the ARM [1] as the base document for the standard, the committees have done a lot more than just clarify the C++ language definition; they have been changing existing features and adding new ones at a fairly steady clip. CD registration represents, among other things, a tacit statement from the committees that they're more or less done adding new stuff. The words in the draft are not yet as clear or as precise as they will be when the standard is final, but at least now the draft describes most, if not all, of the language features we should expect to see in that eventual C++ standard.

Last month, I listed all of the ways the C++ language described by the draft standard differs from the dialect described in the ARM. (See "Stepping Up to C++: C++ at CD Registration," CUJ, January 1995.) My list included only substantive changes (changes in the C++ language itself) and omitted changes that are essentially editorial (changes in the description of C++, not in C++ itself).

I classified the substantive changes into four broad categories:

• major extensions that dramatically increase the complexity of the language and support alternative programming styles and paradigms
• minor enhancements that extend the language in less dramatic ways
• changes that alter the meaning of existing features
• clarifications of existing features

• templates
• exception handling
• run-time type information (including dynamic_cast)
• namespaces

This month, I continue in the same vein with explanations of the minor enhancements. Some of these review features I described in earlier columns. (See "Stepping Up To C++: Recent Extensions to C++," CUJ, June, 1993, and "Stepping Up To C++: The Return Type of Virtual Functions," CUJ, March, 1994.) Stroustrup [2] offers more insights and examples on most of these features.

New Keywords and Digraphs

Computer systems that support non-English alphabets usually make room for native language characters and punctuation by omitting other punctuation characters normally found on American English systems. For example, Danish keyboards, displays, and printers replace the [ and ] with and , respectively. A subscript expression like a[i] comes out on a Danish display device looking like ai. I can imagine that this takes some of the fun out of programming in C and C++.

ISO646 is the international standard 7-bit character set. It specifies the set of characters common to all systems based on the Roman alphabet. ISO646 does not use every available 7-bit code. Each nationality can define its own variant of ISO646 that uses the unused codes for native language characters or symbols. ASCII, the US national variant of ISO646, uses the available codes for symbols like {, }, [, ], /, ^, \, and ~ (all of which are used in C and C++). Other national variants assign these same codes to other alphabetic characters, like or , or to punctuation like .

A current trend in international standards is to augment programming languages so that programmers can work without too much inconvenience using only the invariant set of ISO646 characters. As part of this trend, C++ includes new keywords and digraphs (two-character symbols) as alternate ISO646-compliant spellings for the troublesome operators. These keywords and digraphs appear in Table 1. Using the digraphs, you can write the subscripting expression a[i] as a<:i:>.

ISO C provides the same alternate spellings; however, C specifies the identifiers in Table 1 as macros defined in a standard header <iso646.h>. Thus, you can continue using those identifiers as user-defined identifiers in C as long as you don't include <iso646.h>. However, C++ treats these identifiers as reserved words; you cannot use them as user-defined identifiers in any C++ program. The C++ library provides a header <iso646.h> (which may be empty) just for compatibility with C.

Operator Overloading on Enumerations

For example, given

enum day { SUN, MON, ..., SAT };

enum day d = 0;

int n = SUN;

C++ does not allow operator overloading on primitive types, such as int. When enumerations were integral types, C++ could not allow operator overloading on enumerations either, without severely complicating the rules for overload resolution. Once enumerations became distinct types, allowing overloading on enumerations became a relatively small change.

Removing enumerations from the integral types introduced a potentially serious incompatibility with C, namely, that various built-in arithmetic operators, such as ++, —, += and -=, no longer apply to enumerations. Therefore, a loop such as

for (d = SUN; d <= SAT; ++d)

inline day &operator++(day &d)
   {
   return d = day(d + 1);
   }

operator new[] and operator delete[]

void *operator new(size_t n);

px = new X;

px = (X *)operator new(sizeof(X));
px->X();    // apply constructor

void operator delete(void *p);

delete px;

px->~X();  // apply destructor
operator delete(px);

Writing replacements for the global allocator and deallocator can be a big chore, and it's usually unnecessary. Often all you need to do is tune the memory allocator for objects of a few particular classes. C++ lets you define a different allocator and deallocator for each class. For example,

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

p = new node;

delete p;

According to the ARM, allocating an array of X objects always uses the global operator new, even if X is a class that defines its own operator new. That is,

px = new X[n];

delete [] px;

The current C++ draft standard gives programmers greater control over dynamic memory management for arrays of objects. Now, a new expression such as

px = new X[n];

void *operator new[](size_t n);

delete [] px;

void operator delete[](void *p);

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

p = new node[n];

Relaxed Virtual Function Return Typ es

class B
   {
public:
   virtual int vf(int);
   ...};
class D : public B
   {
   ...
   void vf(int); // error
   ...
};

Some applications need to be able to clone (create an exact copy of) an object. Typically, a cloning function for a class X looks something like

X *X::clone() const
   {
   return new X(*this);
   }

When used in a class that's the root of a polymorphic hierarchy, clone functions should be virtual (possibly pure), so you can clone an object without knowing its exact type. For example, Listing 1 shows a simple hierarchy of geometric shapes with a virtual clone function. Using these types, a call such as

shape *cs = s->clone();

Normally, a clone function for a class X should have a return type of X *. However, in Listing 1, circle::clone returns a shape *, not a circle *, to satisfy the ARM's restriction that an overriding function must return exactly the same type as the function it overrides. Unfortunately, satisfying this restriction often requires you to use casts in contexts where it seems that you should not need them. For example, you cannot write

rectangle *r;
...
rectangle *cr = r->clone();

rectangle *cr = (rectangle *)r->clone();

By and large, the ARM's restriction still stands. The current draft simply adds two special cases where the return types need not match exactly. Specifically, for all classes B and D defined as

class B
   {
   ...
   virtual BT f();
   ...
   };
class D : public B
   {
   ...
   DT f();
   ...
   };

1. BT is BB * and DT is DD *, where DD is derived from BB.

2. BT is BB & and DT is DD &, where DD is derived from BB.

In either case (1) or (2),

3. class D must have the access rights to convert a BB * (or BB &) to a DD * (or DD &, respectively).

In most applications with hierarchies like this, BB is a public base class of DD, so D can perform the conversions. But if, for example, BB is a private base class of DD, then condition (3) does not hold. The above rules apply even if D is derived indirectly from B. Furthermore, BB might be B and DD might be D, as is the case with clone functions.

Types BB and DD, above, may include cv-qualifiers (const and volatile). These qualifiers in BB and DD need not be identical, as long as every qualifier that's part of DD is also part of BB. BB may have qualifiers that are not part of DD.

wchar_t as a Distinct Type

The C++ committees wanted to support input/output for wide characters as well as "narrow" characters. For example, for a time they wanted to be able to add another output operator

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

ostream &operator<<(ostream &os,
                char c);
ostream &operator<<(ostream &os,
                int i);
                //and many others

int i;
wchar_t w;

cout << i;

cout << w;

The problem is that a typedef is not a distinct type; it's an alias for another type. If the library defines wchar_t as

typedef wchar_t int;

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

Thus, wchar_t is now a keyword in C++ representing a distinct type. wchar_t still has the same representation 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.

A Built-in Boolean Type

Those of us who truly felt the absence of a Boolean type defined one ourselves. Unfortunately, there are an awful lot of different ways to do it. Some programmers spell the type as bool. Others use Bool, boolean, Boolean, bool_t, or even logical. The type can be char or int, signed or unsigned. The definition itself can be a macro

#define bool int
#define false 0
#define true 1

typedef unsigned char bool;

enum bool { false, true };

The C++ standards committees decided to eliminate these conflicts by defining a standard Boolean type. C++ now has a Boolean type with the following properties:

• bool is a keyword designating a signed integral type.
• false and true are keywords designating constants of type bool.
• bool expressions promote to int such that false converts to zero and true converts to one.
• int and pointer expressions can convert to bool such that zero converts to false and non-zero converts to true.

• The built-in relational operators <, >, ==, !=, <=, and >= yield a bool result.
• The built-in logical operators &&, //, and ! take bool operands (or operands that automatically convert to bool) and yield a bool result.
• The conditional expression in an if, while, or for statement, or the first operand of ?:, must have bool type (or a type that automatically converts to bool).

The committees agreed to preserve, at least for the time being, the sloppy but apparently common coding practice of using ++ to set a Boolean value to true. C++ currently accepts prefix and postfix ++ as lvalue, of type bool, both of which set to true. However, the draft deprecates this feature, meaning it may disappear from some future standard.

By the way, the committees did explore alternatives to defining bool as a built-in type. They considered defining it in the library as a typedef, as a class, or as an enumeration, but each approach had flaws.

The problem with a typedef is that it is not a distinct type for overloading. If the library defines

typedef int bool;

void f(int);
void f(bool);

Defining bool as a class type poses a different problem. Given the current rules for applying user-defined conversions during argument-matching, defining bool as a class might break existing code. In their analysis of the Boolean type, Dag Brck and Andrew Koenig used an example similar to the one in Listing 2 to illustrate the problem.

Listing 1 shows a class X with a constructor that accepts a single int argument. Thus, that constructor is also a user-defined conversion from int to X. In the absence of a bool type, the expression n > 0 yields an int. The call f(n > 0) uses the constructor X(int) to convert that int result to X, and then passes that X to f(X).

Now suppose C++ defined bool as a class type with a conversion to int:

class bool
   {
public:
   operator int();
   ...
   };

When enumerations were still integral types, it might have been possible to define bool as an enumeration and preserve the implicit conversions from int to bool. Since int values no longer convert quietly to enumerations, it can't be done without special rules for bool. But that's the same as making bool a built-in type.

Declarations in Conditional Expressions

if (circle *c = dynamic_cast<circle *>(s))
   {
   // c is in scope here...
   }
// but not here

The syntax for such declarations is extremely limited. (The revised grammar appears in Table 2. ) The declaration can declare only one object, and it must have an initializer with = as the delimiter. For example, C++ will not accept

if (complex z(r, i))

if (complex z = complex(r, i))

The scope of a name declared in the condition of an if statement includes the else part. For example,

if (int c = getchar())
   {
   // c is non-zero here
   }
else
   {
   // c is zero here
   }
//c is undefined here

while (X *p = iter.next())
   {
   char *p;    // error, p already declared
   ...
   }

References

[2] Bjarne Stroustrup. The Design and Evolution of C++. (Addison-Wesley, 1994).