Re: Future of C++
class Base {
public:
virtual perform() = 0;
protected:
~Base() {} // non-virtual destructor
};
class Derived : public Base {
[snip]
};
int main()
{
std::auto_ptr<Base> pb(new Derived);
[snip]
This shouldn't compile since std::auto_ptr<Base> cannot call Base dtor
(via delete operator).
Unlike Java, 'protected' in C++ only gives access to derived classes.
Theoretically, you *can* construct pathological code where Derived
tries to destroy an instance of *itself* via Base destructor. However,
I doubt you'll ever find such code in practice.
Indeed, I stand corrected. I should have taken the time to try to
compile the code to test my assumption, at least with the excellent free
online Comeau compiler. Mea culpa.
BUT, since we're talking code you'd be likely to see in the real world,
neither will you see abstract base classes with protected destructors.
They are _meant_ to be used for using derived class objects through
pointers (or references) to base class types - such as Object, in Java.
So it wouldn't work to simply make the destructor protected, as that
would break the whole basic object-oriented design.
Furthermore, you might be interested in reading these slides written by
Bjarne Stroustrup in the early stages of debate over C++0x:
http://www.research.att.com/~bs/C++0x_panel.pdf
I quote: "Remove embarrassments ? Frequent questions, frequent novice
errors: [...] Give a class with virtual functions a virtual destructor
by default". You'll find that comment on the last page, page 8 of the slide.
There's also this nice passage in "Thinking in C++", Vol. 2, by Bruce
Eckel, where _exactly_ your protected destructor example is being discussed:
http://www.linuxtopia.org/online_books/programming_books/c++_practical_programming/c++_practical_programming_221.html
Again, quote: "It is evident that this is not a standalone class because
its constructor is protected; it requires a friend or a derived class to
use it. It is important that the destructor is virtual, because it is
called only from the delete this statement in detach( ), and we want
derived objects to be properly destroyed.[122]"
So there we have a "delete this;" issue, that I believe
_you_will_encounter_in_real_life_ often enough. Clicking on note [122]
will further carry us to this: "[122] Even more importantly, we don't
want undefined behavior. It is an error for a base class not to have a
virtual destructor."
So if I'm wrong, and having virtual destructors for all of your base
classes is "nonsense", at least I'm in good company ;-).
Because COM relies on virtual table layout to achieve binary
interoperability between code written by different people in different
languages. If you silently change vtable layout of existing code it
will fail to talk to code built with an earlier compiler.
COM+ works with _interfaces_. Interfaces, being only specifications for
how data should behave, do not emply destructors one way or the other (I
believe COM+ objects do whatever cleanup they need to do upon calling
Release()). It's very fishy to ponder C++ destructors in the context of
a binary component framework such as COM+ or CORBA.
I'll admit that I don't know for sure how the change might affect legacy
COM+ code (though even finding that it does, there are usually compiler
switches that allow deprecated behaviour) - but it might be (and it is,
with some compilers) that the destructors are the last entry in the
vtable, and simply adding one entry at the end would not significantly
change anything in a vptr/vtable-based approach to "binary
interoperability" (since you'd work with the same offsets for all your
old functions).
--
Razvan Cojocaru
KeyID: 1024D/04CA34DE
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]