In article <1116892077.390717.257770@g14g2000cwa.googlegroups.com>,
Marcus <yuu@yyhmail.com> writes
>
>Peter Dimov escreveu:
>> As others have already pointed out, adding an implicit virtual
>> destructor in this case breaks binary compatibility.
>
>I don't think binary compatibility is a strong point of C++... ;-) C is
>much better at that.
>Also, a "compatibility switch" in the compiler could solve that,
>couldn't it?

The last estimate I heard for the cost of breaking binary compatibility
in C++ was $1 billion+ and no one in the room wanted to argue with that
estimate. Binary compatibility in this sense concerns existing ABIs such
as that of Sun Microsystems. Though these are not necessarily portable
elsewhere they are important to people with large code bases locked into
libraries and other archives.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Marcus" <yuu@yyhmail.com> skrev i meddelandet
news:1116790176.508520.177050@o13g2000cwo.googlegroups.com...
> Hello!
>
> I was thinking about improvements that could be made to the C++
> language in order to make it easier for beginners (and for expert
> users
> as a side-effect). Then the non-virtual destructor problem came to my
> mind.
>
> It's considered good practice to declare a virtual destructor if a
> class has at least one virtual function. Failing to do so could easily
> lead to undefined behavior. So, why not make the language take care of
> this?
>
> As a real-world example, when a programmer wants to imitate Java or C#

Why would anyone want to do that?  :-)


> interfaces, he/she needs to write something like this:
>
> struct PureAbstractClass
> {
>  virtual void do_this() = 0;
>  virtual void do_that() = 0;
>  virtual ~PureAbstractClass() {}
> };
>
> It's easy to forget the destructor and it's easy to be unaware that
> it's necessary.

It is only necessary if you want to delete the concrete subclasses
through a pointer to the base class. That is not a given!

Adding a virtual destructor just becase a class has another virtual
function would break the "you don't pay for what you don't
use"-principle. That is an important part of C++.

I sometimes use virtual functions, but can not remember ever using
delete through pointer-to-base.


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcus wrote:
> Hello!
>
> I was thinking about improvements that could be made to the C++
> language in order to make it easier for beginners (and for expert
users
> as a side-effect). Then the non-virtual destructor problem came to my
> mind.
>
> It's considered good practice to declare a virtual destructor if a
> class has at least one virtual function. Failing to do so could
easily
> lead to undefined behavior. So, why not make the language take care
of
> this?
>
> As a real-world example, when a programmer wants to imitate Java or
C#
> interfaces, he/she needs to write something like this:
>
> struct PureAbstractClass
> {
>   virtual void do_this() = 0;
>   virtual void do_that() = 0;
>   virtual ~PureAbstractClass() {}
> };

As others have already pointed out, adding an implicit virtual
destructor in this case breaks binary compatibility.

It's much better to leave the implicit destructor nonvirtual but make
it protected (when the class is abstract). This does not impact binary
compatibility and breaks no valid code.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Peter Dimov wrote:
>
> It's much better to leave the implicit destructor nonvirtual but make
> it protected (when the class is abstract). This does not impact binary
> compatibility and breaks no valid code.
>

I like that. Has it been formally proposed or it's just an idea?

Alberto

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Peter Dimov escreveu:
> As others have already pointed out, adding an implicit virtual
> destructor in this case breaks binary compatibility.

I don't think binary compatibility is a strong point of C++... ;-) C is
much better at that.
Also, a "compatibility switch" in the compiler could solve that,
couldn't it?

> It's much better to leave the implicit destructor nonvirtual but make
> it protected (when the class is abstract). This does not impact
binary
> compatibility and breaks no valid code.

If this is better, I am all in favour of it. I just wanted to remove a
pitfall from the language. My main gripe with this problem is the
"undefined behavior" part. Code that seems to work at first but is, in
fact, undefined behavior is what makes C++ harder than it needs to be.

Bo Persson escreveu:
> Adding a virtual destructor just becase a class has another virtual
> function would break the "you don't pay for what you don't
> use"-principle. That is an important part of C++.

The objects will have a pointer to the v-table anyway (because of the
other virtual function), so what's the overhead? Slightly slower
'delete's? Could that be a performance bottleneck? Non-polymorphic
classes like Point, complex and the like will still be fast.

> I sometimes use virtual functions, but can not remember ever using
> delete through pointer-to-base.

Well, we can't use the whole language all the time. The useless feature
for me may be the main reason for somebody else to choose C++. The code
I'm working now has objects that are used only through a pointer to its
base class, so they're going to be deleted through a pointer to base
too. Besides, since all destructors (in that program) are trivial, it
gets even easier to forget to declare them.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <K7tke.114410$IN.1950421@twister2.libero.it>, Alberto Barbati
<AlbertoBarbati@libero.it> writes
>Peter Dimov wrote:
>>
>> It's much better to leave the implicit destructor nonvirtual but make
>> it protected (when the class is abstract). This does not impact binary
>> compatibility and breaks no valid code.
>>
>
>I like that. Has it been formally proposed or it's just an idea?

I do not think so, but let us not loose the idea. However as this
impacts on the type system it needs to wait until the current work on
laying an agreed and comprehensive baseline has been done. There has
been too much patching in this area of C++.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello!

I was thinking about improvements that could be made to the C++
language in order to make it easier for beginners (and for expert users
as a side-effect). Then the non-virtual destructor problem came to my
mind.

It's considered good practice to declare a virtual destructor if a
class has at least one virtual function. Failing to do so could easily
lead to undefined behavior. So, why not make the language take care of
this?

As a real-world example, when a programmer wants to imitate Java or C#
interfaces, he/she needs to write something like this:

struct PureAbstractClass
{
  virtual void do_this() = 0;
  virtual void do_that() = 0;
  virtual ~PureAbstractClass() {}
};

It's easy to forget the destructor and it's easy to be unaware that
it's necessary. The C++ FAQ-Lite
(http://www.parashift.com/c++-faq-lite/index.html) had this mistake for
some time (now corrected).

I think this feature will not break any code (could even correct sloppy
code! :-) ) and the wording should be simple. G++ already issues a
warning about this, so it seems to be implementable.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcus wrote:

> Hello!
>
> I was thinking about improvements that could be made to the C++
> language in order to make it easier for beginners (and for expert users
> as a side-effect). Then the non-virtual destructor problem came to my
> mind.
>
> It's considered good practice to declare a virtual destructor if a
> class has at least one virtual function. Failing to do so could easily
> lead to undefined behavior. So, why not make the language take care of
> this?
>
> As a real-world example, when a programmer wants to imitate Java or C#
> interfaces, he/she needs to write something like this:
>
> struct PureAbstractClass
> {
>   virtual void do_this() = 0;
>   virtual void do_that() = 0;
>   virtual ~PureAbstractClass() {}
> };
>
> It's easy to forget the destructor and it's easy to be unaware that
> it's necessary. The C++ FAQ-Lite
> (http://www.parashift.com/c++-faq-lite/index.html) had this mistake for
> some time (now corrected).
>
> I think this feature will not break any code (could even correct sloppy
> code! :-) ) and the wording should be simple.

Past discussion of this showed that the only breakage would be
of binary compatibility, but that was a sticking point.  Given
perfect foresight, this would have been a feature of C++ from
the first time virtual functions were added -- but I fear it has
little chance of making it into the language now, unless a way
around the binary compatibility problem can be found.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]