Topic: definition of virtual base class
Author: maxtal@physics.su.OZ.AU (John Max Skaller)
Date: Mon, 6 Dec 1993 10:57:19 GMT Raw View
In article <1993Dec05.150740.1414@vedge.com> alan@vedge.com (Alan Rooks) writes:
>
>The ARM defines virtual inheritance with this sentence (sect 10.1, page 200):
>
>"A single sub-object of the virtual base is shared by every base class
>that specified the base class to be virtual."
>
>The wording "shared by every base class" implies (at least to me) that the
>sharing only occurs when the class (that specifies a virtual base class) is
>itself used as a base class.
I think this means that the virtual base class shares the
subobject, not that the class which specifies the virtual inheritance
does the sharing.
>
>In the example that follows this sentence in the ARM, both A and B specify
>V as a virtual base class, and then A and B are themselves used as base
>classes, so A and B share a V. Fine. But what about when the class with
>the virtual base is not used as a base class? Does it share its virtual
I think you have misinterpreted the ARM: it is not
the class WITH the virtual base that shares the subobject but the
virtual base class itself that shares the subobject with all other
such virtual bases.
>base with another virtual base it may have from further up in the inheritance
>hierarchy? For example:
>
>In fact it becomes obvious a couple pages later that the second interpretation
>is intended, because there's a similar example with a diagram (top page 206)
>that makes it clear. So what I'm complaining about is the wording (since
>I just told someone he couldn't do what he wanted to do, then had to go back
>and tell him that he could :-( and :-), after re-reading a section which
>shouldn't really be necessary). Shouldn't it say "every class in this
>inheritance hierarchy," or something similar?
The whole of the ARM is scattered with this kind of imprecision.
In particular, it keeps INCORRECTLY talking about classes in
inheritance heirarchies when it should be talking about
subobjects (instances of base classes) in base-subobject graphs.
Here's a similar bad wording, invented by me:
in various class structures we might say that a function
of a class hides another.
Thats twaddle :-)
What REALLY should be said is that one INSTANCE of a function name
hides another in the base class subobject graph.
I hope you get the point here: the ARM is barely
comprehensible because it has examples and annotations.
The Working Paper is incomprehensible, because it doesnt
have annotations, and because, being a Standard, much less
may be left to the imagination. In particular, its written
in the most imprecise of languages, English. Some of the
people speaking other languages have trouble understanding
what it says at all.
I have trouble understanding what it says too.
Most programmers have less trouble because their COMPILER
tells them most of the rules (by giving errors when they
stuff up).
The committee has a big problem here. Its actually
quite easy to define these things using a bit of mathematics
and a few algorithms. However, doing this will mean most of
the relevant wording will be completely changed. So I expect
the committee to OBJECT to precise definitions. I also
expect WG21 and SC22 to REJECT the WP until it contains them.
So its going to be a long hard struggle, and its quite hard
to see how we'll make schedule if something doesn't give.
The problem is that only someone with direct access to
the WP and the power to make sweeping changes can possibly
fix the WP in time, or even a year late. And that person is
unlikely to want to risk the wrath of the committee by
making those changes. Its hard to see any way of incorporating
this kind of change, except doing lots of them at once
and presenting the upgraded WP for a vote, because lots
of these things are interdependent.
I think the ARM makes a fine reference manual,
especially as a first definition of the language. But it doesnt
cut it as a Standard. Unfortunately there is considerable opposition
to turning the ARM into a Standard, because that will mean the Standard
will not look anything like the ARM.
--
JOHN (MAX) SKALLER, INTERNET:maxtal@suphys.physics.su.oz.au
Maxtal Pty Ltd, CSERVE:10236.1703
6 MacKay St ASHFIELD, Mem: SA IT/9/22,SC22/WG21
NSW 2131, AUSTRALIA
Author: alan@vedge.com (Alan Rooks)
Date: Sun, 05 Dec 1993 15:07:40 GMT Raw View
The ARM defines virtual inheritance with this sentence (sect 10.1, page 200):
"A single sub-object of the virtual base is shared by every base class
that specified the base class to be virtual."
The wording "shared by every base class" implies (at least to me) that the
sharing only occurs when the class (that specifies a virtual base class) is
itself used as a base class.
In the example that follows this sentence in the ARM, both A and B specify
V as a virtual base class, and then A and B are themselves used as base
classes, so A and B share a V. Fine. But what about when the class with
the virtual base is not used as a base class? Does it share its virtual
base with another virtual base it may have from further up in the inheritance
hierarchy? For example:
class V { };
class A : virtual public V { };
class B : public A, virtual public V { };
Do we have this:
V
\
A V
\ /
B
or this:
V
/ \
A |
\ /
B
???
In fact it becomes obvious a couple pages later that the second interpretation
is intended, because there's a similar example with a diagram (top page 206)
that makes it clear. So what I'm complaining about is the wording (since
I just told someone he couldn't do what he wanted to do, then had to go back
and tell him that he could :-( and :-), after re-reading a section which
shouldn't really be necessary). Shouldn't it say "every class in this
inheritance hierarchy," or something similar?
Aside: "every base class" seems also to be wrong because it doesn't say
that the classes have to be in the same inheritance hierarchy. E.g.
class V { };
class A : virtual public V { };
class B : virtual public V { };
class C : public A { };
class D : public B { };
Both A and B are base classes, and they both specify V to be a virtual base
class, but they obviously don't share anything.
--
Alan Rooks Visual Edge Software, St-Laurent (Montreal)
alan@vedge.com or alan%vedge.uucp@iros1.iro.umontreal.ca
Author: alan@vedge.com (Alan Rooks)
Date: Fri, 26 Nov 1993 19:33:58 GMT Raw View
The ARM defines virtual inheritance with this sentence (sect 10.1, page 200):
"A single sub-object of the virtual base is shared by every base class
that specified the base class to be virtual."
The wording "shared by every base class" implies (at least to me) that the
sharing only occurs when the class (that specifies a virtual base class) is
itself used as a base class.
In the example that follows this sentence in the ARM, both A and B specify
V as a virtual base class, and then A and B are themselves used as base
classes, so A and B share a V. Fine. But what about when the class with
the virtual base is not used as a base class? Does it share its virtual
base with another virtual base it may have from further up in the inheritance
hierarchy? For example:
class V { };
class A : virtual public V { };
class B : public A, virtual public V { };
Do we have this:
V
\
A V
\ /
B
or this:
V
/ \
A |
\ /
B
???
In fact it becomes obvious a couple pages later that the second interpretation
is intended, because there's a similar example with a diagram (top page 206)
that makes it clear. So what I'm complaining about is the wording (since
I just told someone he couldn't do what he wanted to do, then had to go back
and tell him that he could :-( and :-), after re-reading a section which
shouldn't really be necessary). Shouldn't it say "every class in this
inheritance hierarchy," or something similar?
Aside: "every base class" seems also to be wrong because it doesn't say
that the classes have to be in the same inheritance hierarchy. E.g.
class V { };
class A : virtual public V { };
class B : virtual public V { };
class C : public A { };
class D : public B { };
Both A and B are base classes, and they both specify V to be a virtual base
class, but they obviously don't share anything.
Alan Rooks Visual Edge Software, St-Laurent (Montreal)
alan@vedge.com or alan%vedge.uucp@iros1.iro.umontreal.ca
--
Alan Rooks Visual Edge Software, St-Laurent (Montreal)
alan@vedge.com or alan%vedge.uucp@iros1.iro.umontreal.ca