GCC 4.0's std::binary_function and non-virtual dtors

Hi, I'm putting together a small project with GCC 4.0 (via MacOS X Leopard and Xcode 3.0), and I keep running into this warning whenever I follow an example out of Bjarne S.'s "The C++ Programming Language": warning: base class 'struct std::binary_function<myClass, myClass, bool>' has a non-virtual destructor And yes, there is *no* dtor explicitly defined for std::binary_function, so I assume we're using a non-virtual default empty dtor instead. I'd expect as much for this particular struct definition (no data members within it, just one reference). But IMO the compiler is correct to flag this folly as a potential bug -- no base class should ever use a non-virtual destructor, let alone a standard library class. Unfortunately, even if I were to ignore this warning, the build system for the ultimate target platform for this work will not; it has a policy of treating all warnings as errors. Any ideas on how I can get around this? Is there another way to use std::binary_function and std::binder2nd that won't trigger these warnings? Or must I just accept that the STL as implemented by GCC is just ever-so-slightly broken? Thanks in advance, -- Dan Caugherty -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Dan Caugherty wrote: > Hi, > > I'm putting together a small project with GCC 4.0 (via MacOS X Leopard > and Xcode 3.0), and I keep running into this warning whenever I follow > an example out of Bjarne S.'s "The C++ Programming Language": > > warning: base class 'struct std::binary_function<myClass, myClass, > bool>' has a non-virtual destructor I don't have a Mac handy, but GCC 4.2.1 on Linux produces no such diagnostic (g++ -ansi -pedantic -Wall) for the following code: #include <functional> struct my_func: std::binary_function<int, int, void> { void operator()(int, int) { } }; int main() { my_func( )(1, 2); } Are you deleting an object of the derived type through a pointer to std::binary_function? > And yes, there is *no* dtor explicitly defined for > std::binary_function, so I assume we're using a non-virtual default > empty dtor instead. I'd expect as much for this particular struct > definition (no data members within it, just one reference). But IMO > the compiler is correct to flag this folly as a potential bug -- no > base class should ever use a non-virtual destructor, let alone a > standard library class. You are over-generalizing. "I don't know of a good reason" does not imply that "there is no good reason." See Boost.MPL for valid examples of public inheritance without virtual destructors, particularly for metafunction forwarding. It is also reasonable to privately inherit a class with a non-virtual destructor as part of the derived type's implementation, especially if this enables EBO. > Any ideas on how I can get around this? Is there another way to use > std::binary_function and std::binder2nd that won't trigger these > warnings? Or must I just accept that the STL as implemented by GCC is > just ever-so-slightly broken? What's broken? It sounds like the problem is with (a) Apple's "enhancements" to the compiler, or (b) your code, or (c) your build configuration. You haven't mentioned any issue with your library implementation. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

On 2008-11-12 09:20:19 -0500, Dan Caugherty <dan.caugherty@gmail.com> said: > > And yes, there is *no* dtor explicitly defined for > std::binary_function, so I assume we're using a non-virtual default > empty dtor instead. I'd expect as much for this particular struct > definition (no data members within it, just one reference). But IMO > the compiler is correct to flag this folly as a potential bug -- no > base class should ever use a non-virtual destructor, let alone a > standard library class. Please describe a situation (other than testing for the base type) in which you would need to convert a pointer to a type derived from binary_function into a pointer to binary_function and then delete the object through the converted pointer. > > Unfortunately, even if I were to ignore this warning, the build system > for the ultimate target platform for this work will not; it has a > policy of treating all warnings as errors. Bad rules make bad systems. > > Any ideas on how I can get around this? Is there another way to use > std::binary_function and std::binder2nd that won't trigger these > warnings? Or must I just accept that the STL as implemented by GCC is > just ever-so-slightly broken? > It's not in the least bit broken. No implementation of binary_function that I know of has a virtual destructor. That would be utterly pointless. -- Pete Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The Standard C++ Library Extensions: a Tutorial and Reference (www.petebecker.com/tr1book) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

On 12 Nov., 21:20, Dan Caugherty <dan.caughe...@gmail.com> wrote: > Hi, > > I'm putting together a small project with GCC 4.0 (via MacOS X Leopard > and Xcode 3.0), and I keep running into this warning whenever I follow > an example out of Bjarne S.'s "The C++ Programming Language": > > warning: base class 'struct std::binary_function<myClass, myClass, > bool>' has a non-virtual destructor > > And yes, there is *no* dtor explicitly defined for > std::binary_function, so I assume we're using a non-virtual default > empty dtor instead. I'd expect as much for this particular struct > definition (no data members within it, just one reference). But IMO > the compiler is correct to flag this folly as a potential bug -- no > base class should ever use a non-virtual destructor, let alone a > standard library class. This is not correct. Virtual destructors are only needed when deleting via a base pointer. > > Unfortunately, even if I were to ignore this warning, the build system > for the ultimate target platform for this work will not; it has a > policy of treating all warnings as errors. > > Any ideas on how I can get around this? Is there another way to use > std::binary_function and std::binder2nd that won't trigger these > warnings? Or must I just accept that the STL as implemented by GCC is > just ever-so-slightly broken? > (A nit: it is not the STL, but the standard C++ library) It is not the library that is broken, but the warning. The only way you can work yourself out of it is by convincing the providers of your build system that this warning is not appropriate or by not using std::binary_function. After all, it is mostly a convenience function that can be spared away with a little extra effort on your side. You could also lobby the gcc folks to only issue the warning when it is needed - namely when an actual delete is performed, but that solution is unlikely to be practical. /Peter -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

On 12 Nov, 21:20, Dan Caugherty <dan.caughe...@gmail.com> wrote: > Hi, > > I'm putting together a small project with GCC 4.0 (via MacOS X Leopard > and Xcode 3.0), and I keep running into this warning whenever I follow > an example out of Bjarne S.'s "The C++ Programming Language": > > warning: base class 'struct std::binary_function<myClass, myClass, > bool>' has a non-virtual destructor > > And yes, there is *no* dtor explicitly defined for > std::binary_function, so I assume we're using a non-virtual default > empty dtor instead. I'd expect as much for this particular struct > definition (no data members within it, just one reference). But IMO > the compiler is correct to flag this folly as a potential bug -- no > base class should ever use a non-virtual destructor, let alone a > standard library class. > > Unfortunately, even if I were to ignore this warning, the build system > for the ultimate target platform for this work will not; it has a > policy of treating all warnings as errors. > > Any ideas on how I can get around this? Is there another way to use > std::binary_function and std::binder2nd that won't trigger these > warnings? Or must I just accept that the STL as implemented by GCC is > just ever-so-slightly broken? > > Thanks in advance, I agree with what others have said. std::binary_function is not broken. Here are a couple of workarounds: 1) Create your own binary_function, and inherit from that instead: template<typename A1, typename A2, typename R> struct BinaryFunction { typedef A1 first_argument_type; typedef A2 second_argument_type; typedef R result_type; virtual ~BinaryFunction() { }; }; 2) Simply add the typedefs directly to your function object, like this: struct MyFunct { typedef int first_argument_type; typedef int second_argument_type; typedef bool result_type; bool operator()(int, int) const { return false; } }; -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Hi Dan Caugherty wrote: > I'm putting together a small project with GCC 4.0 (via MacOS X Leopard > and Xcode 3.0), and I keep running into this warning whenever I follow > an example out of Bjarne S.'s "The C++ Programming Language": > > warning: base class 'struct std::binary_function<myClass, myClass, > bool>' has a non-virtual destructor I guess you are running into a warning caused by the following gcc command line option: -Wnon-virtual-dtor (C++ and Objective-C++ only) Warn when a class has virtual functions and accessible non-virtual destructor, in which case it would be possible but unsafe to delete an instance of a derived class through a pointer to the base class. This warning is also enabled if -Weffc++ is specified. Since std::binary_function in gcc 4.0 doesn't seem to contain any virtual functions, I assume you are deriving a class containing virtual functions from binary_function. This is ok if you never delete such objects using a binary_function pointer. To get rid fo the warning, either remove -Wnon-virtual-dtor or -Weffc++ options, or specify Wno-non-virtual-dtor. -- ------------- Matti Rintala ------------ bitti@cs.tut.fi ------------ Painting is the art of inclusion. Photography is an art of exclusion. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

On Nov 12, 7:18 pm, Jeff Schwab <j...@schwabcenter.com> wrote: > What's broken? It sounds like the problem is with (a) Apple's > "enhancements" to the compiler, or (b) your code, or (c) your build > configuration. You haven't mentioned any issue with your library > implementation. Aha. The answer is (c). I had the -Weffc++ option set. And, from the documentation from GCC (and Apple): If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use grep -v to filter out those warnings. I'll keep this option in place for my own use only. Thanks one and all for your patience, -- Dan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

On Nov 12, 2:20 pm, Dan Caugherty <dan.caughe...@gmail.com> wrote: > the compiler is correct to flag this folly as a potential bug -- no > base class should ever use a non-virtual destructor, let alone a > standard library class. I don't think that is good advice. Make a destructor virtual only when necessary. Check out the C++ FAQ, "[20.7] When should my destructor be virtual?" http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.7 >From the FAQ, "Here's a simplified rule of thumb that usually protects you and usually doesn't cost you anything: make your destructor virtual if your class has any virtual functions." The design of your class should dictate whether its destructor should be virtual or not. It is not a good idea to _always_ make it virtual. Rgds, anna -- Sicko (The Documentary) http://missingrainbow.blogspot.com/2008/01/sicko.html -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]