Topic: My comments on proposed standard
Author: b91926@fsgm01.fnal.gov (David Sachs)
Date: 1995/06/29 Raw View
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