omission of "virtual" in overridden method declarations in derived classes
in [C++]
|
Prev: omission of "virtual" in overridden method declarations in derived classes
Next: omission of "virtual" in overridden method declarations in derived classes
From: red floyd on 22 Feb 2010 09:51 On Feb 22, 2:57 pm, Gregory Bok <greg....(a)gmail.com> wrote: > Say you have a class with a virtual method, and then in a derived > class, the virtual method is declared without the "virtual" keyword. > > class A > { > public: > virtual void method(); > > }; > > class B > { > public: > void method(); > > }; > > Is this effectively an emulation of the "final" construct, e.g. this > becomes a leaf class in the absence of other overridable methods? No. See 10.3/2 > Does this impact the ability to treat instances of B polymorphically? No. > Or is the virtuality inherited implicitly from the root of the > inheritance tree even if it is omitted in intermediate classes? Yes. See 10.3/2 > Is the behavior here implementation dependent? No. It's in the Standard [yes, you guessed it] in 10.3/2 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Lance Diduck on 27 Feb 2010 02:16
On Feb 23, 6:22 am, "Marco Nef" <maill...(a)shima.ch> wrote: > >> Or is the virtuality inherited implicitly from the root of the > >> inheritance tree even if it is omitted in intermediate classes? > > > Yes. C++ does not require the programmer to repeat the 'virtual' keyword > > for a virtual method in a derived class. > > Which is one of the worst "features" of C++ in large projects, as it causes > lots of errors (how do you know that a method is virtual if it is not > written in the declaration of the class you are working with?). It should > also be that base methods can only be called in the direct base class, or > the programmer has to explicitly write a cast to skip a hierachy level. > > Some time ago I asked to change this in the new standard, so that virtual > must be repeated in derived classes. But the reply in this group was that > lots of old code would not compile anymore. That was a bad answer, as > compilers could have a flag to ignore such an additional security feature in > old code... > > - Marco A better answer is really "because C++ is not Java." virtual can be used to implement an OO design, but in and of itself is just an implementation detail, and does not always mean "dynamic polymophism on an object." But C++0x will have flags to do what you are asking. See http://en.wikipedia.org/wiki/C%2B%2B0x in the "Explicit virtual function overrides" section. There are good reasons not to repeat the virtual keyword. Say I had a classes struct null{}; struct vallcoator{ virtual void * allocate(unsigned sz)=0; virtual deallocate(void*)=0; ~vallcoator(){}; }; struct vvallcoator:virtual vallcoator{ }; template<class Base> struct allocator:Base{ void * allocate(unsigned sz){return malloc(sz);} void deallocate(void*p){free(p);} }; Now I have a peice of code that is suitable as a 1. allocator<null> a;//standalone object 2. vallcoator* v=new allocator<vallcoator>;//SI polymorphic object 3. struct valloc:virtual vallcoator,protected allocator<vvallcoator>{}; vallcoator* v=new valloc;//mixin object while honoring "you dont pay for what you dont use" and the "dont repeat yourself" rules. If struct allocator was also forced to say "virtual" then this example of policy based design (not OO design) would be much more difficult. But I will agree that in the vast majority of C++ code, there should be some mechanism to check that what you intended to override, hide, etc is actually what happened, and the new standard provides that. Lance -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |