Comments about proposed ANSI/ISO C++ standard sent to X3


I) [class.mi] Section 10.1

All the examples in this section show only the case where all
copies of a duplicated base class are indirect. The only discussion
of the structurally simpler but lexically more complex case, in
which there is a direct copy and 1 or more indirect copies, that
I could find was in section 12.6.2 [class.base.init], and the
language there clearly affirmed the legality of a class so
designed.

In view of the clear legality of a class with distinct direct and
indirect copies of the same base class, the C++ standard needs to
specify proper syntax for:

  a) referring to members of the distinct bases
  b) casting a pointer (or reference) to an object of a derived
     class to a pointer (or reference) of each one of the distinct
     base class subobjects.

II) [class.base.init] Section 12.6.2

There is no discussion of the case of a mem-initializer that specifies
a name denoting both a nonstatic data member and a direct or virtual
base class. Declaring such an initialize to be ill formed would be a
reasonable resolution.

III) [class.base.init] Section 12.6.2

When are parameters of mem-initializers evaluated?

Language in this section clearly hints that the intent of the
standards committee is that each mem-initializer should be treated as
a complete expression with its parameters evaluated after all
previous initialization. However, such a requirement is NOT stated
explicitly.

This leaves in limbo code like

 class x{
   int a;
   int b;
   x(int i) : a(i), b(a) {...}
   ...};

which assumes the presence of a sequence point that guarantees
that the initializer for b will use the value of a AFTER a is
initialized.  I have seen published code that blithely assumes such
sequence points.

I would have preferred the alternate resolution, that there are no
such gratuitous sequence points, and that the state of an object is
undefined while mem-initializer parameters are evaluated.

IV) [class.copy] section 12.8

The requirement that a constructor for a class X of the form
X(volatile X&) or X(const volatile X&) is NOT a copy constructor,
and the similar requirement for operator= should be EMPHASIZED,
rather than relegated to an appendix.

I would suggest including an example like the following:

class X
{
  public: X(volatile X&) {} // NOT a copy constructor
};

X a;
X b=a;  // error - ambiguous - X(volatile X&) or default X(const X&)
--
** The Klingons' favorite food was named by the first earthling to see it **
David Sachs - Fermilab, HPPC MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 708 840 3942      Deparment Fax: 1 708 840 3785