The left-hand side of a member access expression can by itself be a non-trivial expression, as in a[f(i)].m or (++p)->g(x). As you might expect, a program normally evaluates the left-hand side of a member access expression to determine the object containing the specified member. However, according to the ARM Section 9.4 [StaticMembers]:

When a static member is accessed through a member access operator, the expression on the left side of the . or -> is not evaluated.

For example, if m is a static data member, then according to the ARM, a[f(i)].m does not call f(i). Similarly, if g is a static member function, then (++p)->g(x) does not increment p.

Although this special rule for accessing static members eliminates some potentially inefficient code, the committees decided it led to inconsistent, and potentially surprising, results. Therefore, they eliminated that sentence from the draft. According to the current draft, if a program evaluates a member access expression, it must evaluate the expression on the left-hand side of the . or -> operator.

If this rule change makes sense to you already, and you know how to work around it, you can skip to the next section. If not, stay with me. The key insight comes from understanding static class members, which I'll explain with the following example.

Suppose your application uses a class called widget, and you want to track the number of widget objects in existence at any given time in the execution of your program. Simply define a counter, initialized to zero, that counts the number of objects. Then, add a statement to each widget constructor to increment the counter, as in

widget::widget()
   {
   ++counter;
   // initialize the widget
   }

widget::~widget()
   {
   // discard the widget's resources
   --counter;
   }

class widget
   {
public:
   widget();
   ~widget();
   // other public members...
private:
   unsigned counter;
   // other private members ...
   };

The counter variable must be statically allocated and separate from every widget object so there's one and only one counter for all widget objects. Declaring the counter as a global variable will work, but you run the risk that the name of the counter may conflict with some other global name elsewhere in the program. Also, if it's a global variable, you can't prevent parts of the program outside the widget class from accessing the counter directly. As always, global variables weaken abstractions and you should avoid them.

Static data members solve this dilemma. A static data member is in the scope of its class and is subject to access control (it can be private). However, a static data member is unlike an ordinary data member in that it is not a part of each class object; there's only one copy of the static member, and it is separate from every object. That one copy has static storage duration and external linkage, so that all objects of the class type share the same static member.

For example,

class widget
   {
public:
   widget();
   ~widget();
   // other public members ...
private:
   static unsigned counter;
   // other private members ...
   };

The declaration of a static data member inside a class is only a declaration. The definition (and initialization) of the static member appears elsewhere, typically in a source file along with other members of the class. For widget::counter, the definition looks like

unsigned widget::counter= 0;

cout << "# of widgets = << widget::counter;

unsigned widget::how_many()
   {
   return counter;
   }

However, this implementation of how_many is less than perfect. The problem is that how_many is an ordinary member function. An ordinary member functions always has a hidden extra argument — the object addressed by its this pointer. Therefore, a call to how_many must be of the form w.how_many() (where w is a widget) or p->how_many()(where p is a pointer to a widget). But how_many doesn't need a this pointer to locate widget::count because widget::count is not in a widget object.

In fact, if how_many is an ordinary member function, the logic for testing that there are no widgets becomes a bit contorted:

{
widget w;
if (w.how_many() == 1)
   // there weren't any widgets
// w goes out of scope; destroy it
}

These problems go away if you declare how_many as a static member function:

class widget
   {
public:
   widget();
   ~widget();
   static unsigned how_many();
   // other public members ...
private:
   static unsigned counter;
   // other private members ...
   };

cout << "# of widgets ="
   << widget::how_many();

if (widget::how_many() == 0)
   // there really aren't any widgets

Therein lies the rationale for the ARM's rule that a program need not evaluate the left-hand side of a . or -> in a static member access expression. The access uses the left-hand side only to determine the member's class (at compile time), and then ignores any computational results in accessing the member (at run time). However, some committee members suggested this distinction was just too subtle, and that programmers might be surprised that the left-hand side of an access expression might not be evaluated.

enum day {SUN, MON, TUE, WED, THU, FRI, SAT};
enum day  d;

d = 0;
d++;
d += 2;
d = d+1;

The current C++ draft standard aspires to treat enumerations as distinct types in the mold of these other languages. However, for compatibility with the ARM as well as C, the current draft allows promotions from enumerations to integral types. Specifically, the draft says:

Enumerations are not integral, but they can be promoted to int, unsigned int, long, or unsigned long.

C++ no longer permits any of the expressions shown above, but it still permits declarations like

int n = WED; // promote WED to int

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

As I described in an earlier column ("Stepping Up to C++: Minor Enhancements to C++ as of CD Registration," CUJ, February 1995), the committees compensated for this incompatibility by extending C++ to permit overloading on enumerations. For example, you can write the for loop above by first defining

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

You may, but need not, also declare relational operators for type day, such as

inline int operator<=(day d1, day d2);

d <= SAT

enum color {BLUE, GREEN, RED};

for (day d = SUN; d <= RED; ++d)

Thus, the automatic promotion to an integer type weakens a C++ compiler's ability to keep enumerations distinct from each other. It's unfortunate, but the alternative of leaving a lot of C and older C++ code outside the C++ standard may be worse.

In a separate, but related minor extension, the C++ draft allows an enumeration constant to have a value of an integral type whose size is larger than int. The ARM, like C, states that:

The value of an enumerator must be an int or a value that can be promoted to int by integral promotion.

The current draft now simply says:

The constant-expression [used to initialize the enumerator] shall be of integral type.

Integral types include unsigned int, [signed] long int, and unsigned long int. Thus, C++ now allows enumeration declarations such as

enum big_numbers {MEGA = 1000000, GIGA: 1000000000};

For example, calling a function such as

String operator+(const String &s1, const String &s2)

String operator+(const String &s1, const String &s2)
   {
   String rv;
   // compute result in rv
   return rv;
   }

The lifetime of a temporary object is the period of time during program execution from the temporary's construction until its corresponding destruction. The ARM simply says the lifetime of temporary objects created during expression evaluation is "implementation dependent." That is, a program might destroy each temporary almost immediately, or it might save them up and destroy them all at program termination.

Ideally, C++ programmers shouldn't have to concern themselves with exactly when the temporaries come and go. But they do. If you don't know how your compiler manages temporaries, your program might inadvertently destroy a temporary before it's done with that temporary. Or your program might consume mass quantities of memory keeping temporaries around long after they've outlived their usefulness. If, for example, the aforementioned String class includes a conversion operator

operator const char *() const;

(const char *)(s + t)

printf("%s\n", (const char *)(s + t));

if (strcmp((const char *)(s + t), buf) == 0)

The current draft standard offers much better guidance about the lifetime of temporary objects. It says:

Ordinarily, temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created. This is true even if that evaluation ends in throwing an exception.

As in C, a full-expression is an expression that is not part of another expression. It includes the following:

• an expression statement
• the controlling expression of an if or switch statement
• the controlling expression of an while or do statement
• each of the three (optional) expressions of a for statement
• the optional expression in a return statement

printf("%s\n", (const char *)(s + t));

if (strcmp((const char *)(s + t), buf) == 0)

const char *p;
p = s + t;
printf("%s\n", p);

The draft also describes two contexts in which a program destroys temporaries other than at the end of a full-expression:

The first context is when an expression appears as an initializer for a declarator defining an object. In that context, the temporary that holds the result of the expression shall persist until the object's initialization is complete. The object is initialized from a copy of the temporary; during this copying, an implementation can call the copy constructor many times; the temporary is destroyed as soon as it has been copied.

The second context is when a temporary is bound to a reference. The temporary bound to the reference or the temporary containing the sub-object that is bound to the reference persists for the lifetime of the reference initialized or until the end of the scope in which the temporary is created, which ever comes first. A temporary holding the result of an initializer expression for a declarator that declares a reference persists until the end of the scope in which the reference declaration occurs. A temporary bound to a reference in a constructor's ctor-initializer persists until the constructor exits. A temporary bound to a reference parameter in a function call persists until the completion of the call. A temporary bound in a function return statement persists until the function exits.

Next month, I'll describe more of these language changes.

References