RE: [jira] Resolved: (XERCESC-1464) XMLBufferFullHandler has virt ual method, but not destructor

[Ma...@VerizonWireless.com]

G++ 4.0 has a lot more warnings that old compilers. If the build enabled,
say, -Wall, it would convert many warnings about bad code into full-blown
errors. The thing I would mention here is that it's obviously very bad for a
class to have virtual methods but no virtual destructor. It could range from
memory leaks and stuck resource locks all the way to completely undefined
behavior. I think I pretty much agree with G++'s decision on this even if
it's technically allowed to be done this way.

Matt

N.B., from http://www.gotw.ca/publications/mill18.htm :

...
template <class Arg, class Result>
struct unary_function
{
  typedef Arg    argument_type;
  typedef Result result_type;
};

template <class Arg1, class Arg2, class Result>
struct binary_function
{
  typedef Arg1   first_argument_type;
  typedef Arg2   second_argument_type;
  typedef Result result_type;
};

Both of these templates are specifically intended to be instantiated as base
classes (in order to inject those standardized typedef names into derived
classes) and yet do not provide virtual destructors because they are not
intended to be used for polymorphic deletion. That is, code like the
following is not merely unsanctioned but downright illegal, and it's
reasonable for you to assume that such code will never exist:

// Example 4: Illegal code that you can assume
// will never exist.
//
void f( std::unary_function* f )
{
  delete f; // error, illegal
}

Note that the standard tut-tuts and declares Example 4 to fall squarely into
the Undefined Behavior Pit, but THE STANDARD DOESN'T ACTUALLY REQUIRE A
COMPILER TO PREVENT YOU OR ANYONE ELSE FROM WRITING THAT CODE (more's the
pity). It would be easy and nice - and it wouldn't break any
standards-conforming C++ programs that exist today - to give
std::unary_function (and other classes like it) an empty but protected
destructor, in which case a compiler would actually be required to diagnose
the error and toss it back in the offender's face. Maybe we'll see such a
change in a future revision to the standard, maybe we won't, but it would be
nice to make compilers reject such code instead of just making tut-tut
noises in standardish legalese.

Finally, what if a base class is concrete (can be instantiated on its own)
but also wants to support polymorphic destruction? Doesn't it need a public
destructor then, since otherwise you can't easily create objects of that
type? That's possible, but only if you've already violated another
guideline, to wit: Don't derive from concrete classes. Or, as Scott Meyers
puts it in Item 33 of More Effective C++,[8] "Make non-leaf classes
abstract." (Admittedly, it can happen in practice - in code written by
someone else, of course, not by you! - and in this one case you may have to
have a public virtual destructor just to accommodate what's already a poor
design. Better to refactor and fix the design, though, if you can.)

In brief, then, you're left with one of two situations. Either: a) you want
to allow polymorphic deletion through a base pointer, in which case the
destructor must be virtual and public; or b) you don't, in which case the
destructor should be nonvirtual and protected, the latter to prevent the
unwanted usage.

-----Original Message-----
From: David Bertoni (JIRA) [mailto:xerces-c-dev@xml.apache.org]
Sent: Tuesday, July 19, 2005 12:35 PM
To: c-dev@xerces.apache.org
Subject: [jira] Resolved: (XERCESC-1464) XMLBufferFullHandler has
virtual method, but not destructor


     [ http://issues.apache.org/jira/browse/XERCESC-1464?page=all ]
     
David Bertoni resolved XERCESC-1464:
------------------------------------

    Resolution: Duplicate

This is already fixed in the latest code.  However, I'm curious as to why
compilation would fail, since it's not illegal for a class to have a
virtual function, but no virtual destructor.
___________________________________________________________________
The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure.  If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

RE: [jira] Resolved: (XERCESC-1464) XMLBufferFullHandler has virt ual method, but not destructor

[da...@us.ibm.com]

> G++ 4.0 has a lot more warnings that old compilers. If the build 
enabled,
> say, -Wall, it would convert many warnings about bad code into 
full-blown
> errors.

I don't believe -Wall turns warnings into errors, but perhaps that has 
changed in GCC 4.0.  But at any rate, compiler options are by definition 
non-standard.

> The thing I would mention here is that it's obviously very bad for a
> class to have virtual methods but no virtual destructor. It could range 
from
> memory leaks and stuck resource locks all the way to completely 
undefined
> behavior. I think I pretty much agree with G++'s decision on this even 
if
> it's technically allowed to be done this way.

Yes, it's often a "bad thing," and that's why I added the virtual 
destructor.  However, it's not illegal, and it would have been helpful if 
the person who reported the problem provided more information.

I doubt very much that GCC has decided that something which is perfectly 
legal is now illegal, simply because it's not recommended.

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org