C++0x: [[final]] doesn't prevent derivation
Scott Meyers
> The final attribute to a class declaration and the virtual function declaration can prevent them from being further inherited. A class with the final attribute will not be allowed to be a base class for another class. A virtual function with the final attribute will not be overridden in a subclass.
The proposed wording, which is also in draft C++0x, eliminates the prohibition
on derivation:
> The [final] attribute applies to class definitions and to virtual member functions being declared in a class definition. If the attribute is specified for a class definition, it is equivalent to being specified for each virtual member function of that class, including inherited member functions.
> If a virtual member function f in some class B is marked final and in a class D derived from B, a function D::f overrides B::f, the program is ill-formed; no diagnostic required.
This introduces what is sure to be a surprising change in semantics compared to
the meaning of "final" for classes in Java.
Can anybody explain why [[final]] classes in C++0x don't prevent derivation?
Thanks,
Scott
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Mathias Gaunard
> > The [final] attribute applies to class definitions and to virtual member functions being declared in a class definition. If the attribute is specified for a class definition, it is equivalent to being specified for each virtual member function of that class, including inherited member functions.
> > If a virtual member function f in some class B is marked final and in a class D derived from B, a function D::f overrides B::f, the program is ill-formed; no diagnostic required.
>
> This introduces what is sure to be a surprising change in semantics compared to
> the meaning of "final" for classes in Java.
>
> Can anybody explain why [[final]] classes in C++0x don't prevent derivation?
It might be because derivation has other uses than overriding
functions (strong typedef, empty base class optimization), and that
there is no good reason to prevent such uses.
Scott Meyers
>
> It might be because derivation has other uses than overriding
> functions (strong typedef, empty base class optimization), and that
> there is no good reason to prevent such uses.
Then why use the word "final," which already has a different and
well-recognized meaning in a related language? Why not something like
"all_final," which, if nothing else, is substantially less likely to
confuse people?
Scott
Sean Hunt
> Then why use the word "final," which already has a different and
> well-recognized meaning in a related language? Why not something like
> "all_final," which, if nothing else, is substantially less likely to
> confuse people?
>
> Scott
Java certainly hasn't done any favours to us (*coughnewcough*).
Sean Hunt
Nick Hounsome
> N2761 introduces the notion of [[final]] applied to a class this way:
>
> > The final attribute to a class declaration and the virtual function declaration can prevent them from being further inherited. A class with the final attribute will not be allowed to be a base class for another class. A virtual function with the final attribute will not be overridden in a subclass.
>
> The proposed wording, which is also in draft C++0x, eliminates the prohibition
> on derivation:
>
> > The [final] attribute applies to class definitions and to virtual member functions being declared in a class definition. If the attribute is specified for a class definition, it is equivalent to being specified for each virtual member function of that class, including inherited member functions.
> > If a virtual member function f in some class B is marked final and in a class D derived from B, a function D::f overrides B::f, the program is ill-formed; no diagnostic required.
>
> This introduces what is sure to be a surprising change in semantics compared to
> the meaning of "final" for classes in Java.
Java was derived from C++ not the other way around. I don't think Java
compatibility has been, or ever will be, a consideration for C++.
> Can anybody explain why [[final]] classes in C++0x don't prevent derivation?
In Java methods are normally virtual (virtual in C++).
In C++ methods are normally not virtual (final in Java)
There is no good reason to prevent derivation from a class (in any
language) unless it allows you to access protected data or to alter
behaviour.
If, with a final class, you are prevented from altering behviour by
overriding methods and prevented from priveleged access (I don't know
what's in the draft but a protected section in a [final] class
wouldn't make much sense) then why not allow derivation?
There are many reasons to want to do this.
P.S. I suspect that, for Java, there might be some advantages when it
comes to bytecode checking in the VM which is a level of security not
possible in C++.
James Kanze
> N2761 introduces the notion of [[final]] applied to a class this way:
> > The final attribute to a class declaration and the virtual
> > function declaration can prevent them from being further
> > inherited. A class with the final attribute will not be
> > allowed to be a base class for another class. A virtual
> > function with the final attribute will not be overridden in
> > a subclass.
> The proposed wording, which is also in draft C++0x, eliminates
> the prohibition on derivation:
> > The [final] attribute applies to class definitions and to
> > virtual member functions being declared in a class
> > definition. If the attribute is specified for a class
> > definition, it is equivalent to being specified for each
> > virtual member function of that class, including inherited
> > member functions. If a virtual member function f in some
> > class B is marked final and in a class D derived from B, a
> > function D::f overrides B::f, the program is ill-formed; no
> > diagnostic required.
> This introduces what is sure to be a surprising change in
> semantics compared to the meaning of "final" for classes in
> Java.
> Can anybody explain why [[final]] classes in C++0x don't
> prevent derivation?
Probably because people don't want to prevent derivation, even
if there are no functions which can be overridden. Derivation
is used in several template meta-programming idioms (e.g. is the
type a class type?), in cases where in fact, there will be no
instances of the derived class.
Not being able to override the definition of a virtual function
is important with regards to maintaining class invariants. I've
yet to find any important use for not being able to derive from
a class.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
James Kanze
> Mathias Gaunard wrote:
> > It might be because derivation has other uses than
> > overriding functions (strong typedef, empty base class
> > optimization), and that there is no good reason to prevent
> > such uses.
> Then why use the word "final," which already has a different
> and well-recognized meaning in a related language? Why not
> something like "all_final," which, if nothing else, is
> substantially less likely to confuse people?
Maybe because Java and C++ are different languages. People who
come from Java, and expect the same concepts to apply, are
already going to have more than a few problems; this one more
isn't going to change anything. (Note that the same thing is
true in the opposite sense---I know I had problems with
protected in Java, at first, because I simply applied the C++
meaning.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
Hendrik Schober
> [...]
> Java was derived from C++ not the other way around. I don't think Java
> compatibility has been, or ever will be, a consideration for C++.
The same approach taken by the C community towards C++ has done
a disservice to both C and C++.
(See here
<http://www.research.att.com/~bs/siblings_short.pdf>
<http://www.research.att.com/~bs/compat_short.pdf>
<http://www.research.att.com/~bs/examples_short.pdf>
for a discussion.)
> [...]
Schobi
Sean Hunt
> Can anybody explain why [[final]] classes in C++0x don't prevent derivation?
So, as it turns out, we're all defending an empty castle. CWG issu 817
(http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2936.html#817)
indicates that they do indeed want it to prevent derivation.
James Kanze
> Nick Hounsome wrote:
> > [...]
> > Java was derived from C++ not the other way around. I don't
> > think Java compatibility has been, or ever will be, a
> > consideration for C++.
> The same approach taken by the C community towards C++ has done
> a disservice to both C and C++.
There's a major difference. Java never tried to be C or C++
compatible---expression syntax is quite similar, and both use
curly braces, but that's about where the similarity ends. C++
definitely does try to maintain some degree of compatibility
with C, and there is a large body of header files designed to be
compiled in both C and C++.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
Hendrik Schober
> On Aug 4, 9:13 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> Nick Hounsome wrote:
>>> [...]
>>> Java was derived from C++ not the other way around. I don't
>>> think Java compatibility has been, or ever will be, a
>>> consideration for C++.
>
>> The same approach taken by the C community towards C++ has done
>> a disservice to both C and C++.
>
> There's a major difference. Java never tried to be C or C++
That's certainly true.
Schobi