Re: Tiger Build Warnings
Re: Tiger Build Warnings
- Subject: Re: Tiger Build Warnings
- From: Ben Cox <email@hidden>
- Date: Thu, 23 Jun 2005 10:21:04 -0400
I had forgotten that this class was a COM-like interface.
In the general case, the potential danger here is that someone will
do this:
AbstractBaseClassWithoutVirtualDestructor *p(something());
p->doStuff();
delete p;
When someone deletes the object through the pointer to a base class
that has a non-virtual destructor, the results are undefined, as
Meyers says.
However, in this case Jeff is correct in that this latent bug will
never be hit; for an interface class like this one, the usage pattern
I showed above will (had better!) never occur. For objects "derived
from" (that implement) AUElementCreator, the user will really do
something like:
AUElementCreator *p(something());
p->doStuff();
p->Release();
and the derived class' virtual Release() method will do "delete
this;" if/when the refcount drops to zero. Thus the danger of
"delete p;" on a pointer to the base class is averted by programming
convention/requirements, and the warning is, in this case,
superfluous. (If someone does actually do "delete p;" then they
likely have bigger bugs in their program than this one.) Actually
adding a virtual destructor as Richard suggests would cause problems
with the vtable layout, which would interfere with COM-like use of
the interface class.
So, I retract my comment last night that AUElementCreator contained a
bug. Sorry.
I thought there was a G++ attribute you could define (with
__attribute__) on the interface class to suppress the warning, but I
can't find it at the moment.
(Note: you can't just make IUnknown have a protected non-virtual
empty destructor to enforce the usage pattern; that wouldn't prevent
people from doing "delete p;", since many of the callers will derive
from IUnknown too.)
-- Ben
On Jun 23, 2005, at 4:56 AM, Richard Dobson wrote:
From Meyers, "Effective C++" (2nd Ed), Item 14:
"Make sure base classes have virtual destructors". Among other points:
"[from the C++ standard] if you try to delete a derived class
object through a base class pointer and the base class has a non-
virtual destructor, the results are undefined" ..."What often
happens at runtime is that the derived class's destructor is never
called".
Thus, the non-virtual destructor could become the source of memory
leaks.
In short: because
(a) this is clearly a base class (or interface; pure virtual base
class here)
(b) it has virtual functions
it should have a virtual destructor.
Finally, assuming the definition in Tiger is the same as in
Panther, the class is defined only with a pure virtual constructor,
leaving a default destructor to be defined by the compiler. This
default destructor is non-virtual, leading to the warning. It is
probably Ok to define one inline:
virtual ~AUElementCreator() {}
The relevant part of the standard is $12.4: destructors.
Richard Dobson
Jeff Moore wrote:
In general, I like to see warnings from my compilers. They
usually point out potential problems. However, in this particular
case, the warning is a little off-base.
AUElementCreator does not inherit from any other classes, has no
member fields, and has no member functions that aren't pure
virtual. In other words, it is an abstract base class. It's job
it to define an interface. In fact, it is specifically meant to
be a mix-in class. Such a class does not need a destructor, let
alone a virtual one. It just doesn't accomplish anything to call it.
One might even argue that having to define a virtual destructor
in this case is actually bad since it takes away the compiler's
ability to optimize the un-named function completely away, which
is what happens since it won't get any code generated to call it
when a sub- class's destructor is generated.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
__
Ben Cox <email@hidden>
http://www.djehuti.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden