Re: Static Class Variables, Inheritance, and Polymorphism
On Apr 5, 3:37 pm, "crjjrc" <crj...@gmail.com> wrote:
On Apr 5, 4:53 am, "James Kanze" <james.ka...@gmail.com> wrote:
I've then got a vector declared to hold instances of Base, but it=
's
actually filled with various instances of Derived1 and Derived2.
No it's not. A vector always holds instances of the type it was
declared with. If you declare std::vector<Base>, it will hold
instances of Base, and nothing else. This is one of the most
important invariants of std::vector.
I should have clarified -- I declared a vector to hold pointers to
instances of Base.
Yes. You should have been precise. Precision is an important
quality when programming.
It
seems like the parent's getType should pull the variable type from the
child for instances of Derived1 and Derived2. type should be a
"virtual" member, I would think.
Why? You haven't declared it virtual.
In my first post, I said I tried declaring getType() as virtual.
And if you override getType() in the derived classes, the
overriding version gets called, no.
For various reasons, in
fact, data members can't be virtual; only functions. And of
course, static members can't be virtual. Perhaps the reason
data members can't be virtual is because it only makes sense for
static data members; the reason static members can't be virtual
is that virtuality is based on the actual (dynamic) type of the
object, and static members don't have an associated object, so
it doesn't make sense either.
I believe this last comment contains an inconsistency. You say that
virtuality is based on class, but since static members don't have an
associated instance, virtuality doesn't make sense.
Virtual resolution is based on the dynamic type of the actual
*object*, not on the static type (the class) that the compiler
sees.
Well, static members do have an associated class.
But they don't have an associated object. So what do you base
the dynamic type on?
If I've got an object of a
derived class, I'd argue that I should be able to access the type
member of the respective class without having to replicate the exact
same function in all derived classes.
In sum, you're arguing for virtual data members. The language
doesn't support them, for various reasons. If you think it
should, write up a proposal, with a detailed and precise
explination of 1) what the benefits of this are, and 2) how it
can be implemented, and the committee will doubtlessly consider
it. (Actually, implementation is fairly trivial, but for the
moment, I fail to see any real benefits, and I can see a lot of
dangers in it.)
If I called a virtual function
in the parent's getType(), would I not access the definition of the
function in the derived class?
Yes. If you declare the function virtual in the base class.
And this function is associated not
with a particular object, but with the object's class.
When you call a non-static member function, you associate it
with an object.
A consistent
language should use overridden members just as they use overridden
functions.
C++ does. You didn't declare the data element virtual, so it is
not treated as virtual.
Why should data and code be treated differently?
It isn't, in C++. Except, of course, that you cannot declare
data virtual.
This is
a serious question. I'm not trying to argue, and I'd like to really
know why this is the case.
Nevertheless, C++ isn't designed this way. I don't see a compelling
reason why it is not. My solution mentioned in my first post just
avoids members altogether, with functions that return a literal in
each derived class. That makes the most sense for what I need to do.
That's the usual solution. The general philosophy in an OO-type
class is that data is an implementation detail of the class
itself; all that counts is functions. One can argue whether
this is right or not, but there is certainly historical
precedent: I don't know of any language which supports
polymorphism on data types.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34