Topic: C++0x: [[final]] doesn't prevent derivation
Author: Hendrik Schober <spamtrap@gmx.de>
Date: Sat, 8 Aug 2009 09:54:06 CST Raw View
James Kanze wrote:
> 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++
> compatible [...]
That's certainly true.
Schobi
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Scott Meyers <usenet@aristeia.com>
Date: Fri, 31 Jul 2009 11:57:56 CST Raw View
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?
Thanks,
Scott
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Mathias Gaunard <loufoque@gmail.com>
Date: Fri, 31 Jul 2009 15:37:46 CST Raw View
On 31 juil, 19:57, Scott Meyers <use...@aristeia.com> wrote:
> > 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.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Scott Meyers <usenet@aristeia.com>
Date: Fri, 31 Jul 2009 23:51:58 CST Raw View
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?
Scott
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Sean Hunt <rideau3@gmail.com>
Date: Sat, 1 Aug 2009 02:15:01 CST Raw View
On Jul 31, 11:51 pm, Scott Meyers <use...@aristeia.com> wrote:
> 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
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Nick Hounsome <nick.hounsome@googlemail.com>
Date: Sat, 1 Aug 2009 11:22:06 CST Raw View
On 31 July, 18:57, Scott Meyers <use...@aristeia.com> wrote:
> 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++.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Sun, 2 Aug 2009 09:52:28 CST Raw View
On Jul 31, 7:57 pm, Scott Meyers <use...@aristeia.com> wrote:
> 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.kanze@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
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Sun, 2 Aug 2009 20:37:52 CST Raw View
On Aug 1, 7:51 am, Scott Meyers <use...@aristeia.com> wrote:
> 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.kanze@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
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Hendrik Schober <spamtrap@gmx.de>
Date: Tue, 4 Aug 2009 13:13:56 CST Raw View
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++.
(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
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Sean Hunt <rideau3@gmail.com>
Date: Wed, 5 Aug 2009 15:21:41 CST Raw View
On Jul 31, 11:57 am, Scott Meyers <use...@aristeia.com> wrote:
> 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.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: James Kanze <james.kanze@gmail.com>
Date: Wed, 5 Aug 2009 15:21:15 CST Raw View
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++
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.kanze@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
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]