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:[EMAIL PROTECTED] Sent: Tuesday, July 19, 2005 12:35 PM To: [email protected] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
