Re: Future of C++
Razvan Cojocaru wrote:
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.
No, it does not. It only removes the possibility of deleting through a
pointer to base.
There are many cases where you might want to adhere to an interface,
without dynamically allocating the derived classes.
[ Some examples deleted]
So if I'm wrong, and having virtual destructors for all of your base
classes is "nonsense", at least I'm in good company ;-).
Having virtual destructors for some, or even many, base classes is s
good idea. Having it for everything, whether you need it or not, is a
less good idea.
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).
Adding an entry at the end would affect derived classes. The number of
virtual functions in the interface is important.
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]