Re: [boost] [statechart] Problems if I make dtorS virtual?
Hi Andreas
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andreas Huber Sent: Wednesday, August 24, 2005 2:19 PM To: boost@lists.boost.org Subject: Re: [boost] [statechart] Problems if I make dtorS virtual?
Hi Dick
BRIDGES Dick wrote:
When compiling the examples (statechart library downloaded from sf 18 Aug), I get the following warnings:
[snip warnings]
I changed ~simple_State() and ~state_base() to virtual and the warnings disappeared.
As a quick, not-definitive check, I built PingPong* with both the virtual and non-virtual dtorS using gcc 3.4.2 on an old i386-redhat-linux machine.
I would expect the PingPong examples to deliver the least-dependable information regarding virtual vs. non-virtual dtors. This is due to
[snip] the
fact that a lot of stuff is going on besides the destruction of states. I think BitMachine would make for a better testing platform...
The results appear to be the reverse of what I would expect, but I checked to verify that I have the correct result/config correspendence.
..................non-virtual.....virtual PingPongSingle.... 4.08 ..... 3.71 PingPongMulti1.... 6.01997 ..... 5.85999 PingPongMulti2.... 19.53 ..... 19.55
Hmmm, here's what I get on a 3.2GHz Intel Pentium 4 Windows XP machine (all numbers in microseconds non-virtual / virtual):
*** MSVC7.1 ***
PingPongSingle: 1.06 / 1.07 PingPongMulti1: 5.41 / 5.43 PingPongMulti2: 12.34 / 12.26
BitMachineCustom3: 0.18 / 0.19
I.e. no significant difference non-virtual vs. virtual. Two things come to mind: 1. At the point where states are destructed (see simple_state.hpp,
983) the compiler might know that the type of the pointer matches the runtime type of the referenced object and therefore call the virtual destructor non-virtually. However, I'm not sure whether such compiler magic is implemented in any of the tested platforms nor do I have a clue whether that's possible at all (it does sound pretty impossible) 2. There could be little difference on modern processors anyway (as you have mentioned)
Reminds me of the old joke: "I see fine. I just don't understand what I'm looking at." Two questions: 1) will making the dtorS virtual lead to adverse consequences I simply haven't encountered yet;
Given the numbers above I don't see any problems whatsoever. Not on
[snip_similar_results] Looks more like what I would expect. BTW: Could I talk you into trading computers? ;) line the
tested processors, that is. I can't say whether the picture is the same for processors used in the embedded world.
I may know the answer for some ARM machines soon - I hope. ;) I'll try the BitMachine* tests if I can get the cross compilers to build them.
and 2) can someone help me understand what I did wrong in setting up this test?
Difficult to say. Could you build with bjam and repeat the test?
I followed the instructions to build the examples. Changed to the example directory and ran <<bjam "sTOOLS=gcc">>. I got lazy and only ran the PingPong* progs. Guess I should have mentioned that. %>] Any chance that, in the absence of some future evidence to the contrary, those dtorS can be made virtual in the library? [snip]
Regards,
-- Andreas Huber
Regards, Dick Bridges "Multithreading is just one damn thing after, before, or simultaneous with another." Scott Meyers and Andrei Alexandrescu
BRIDGES Dick wrote:
PingPongSingle: 1.06 / 1.07 PingPongMulti1: 5.41 / 5.43 PingPongMulti2: 12.34 / 12.26
BitMachineCustom3: 0.18 / 0.19
[snip_similar_results]
Looks more like what I would expect. BTW: Could I talk you into trading computers? ;)
:-) [snip]
Given the numbers above I don't see any problems whatsoever. Not on the tested processors, that is. I can't say whether the picture is the same for processors used in the embedded world.
I may know the answer for some ARM machines soon - I hope. ;) I'll try the BitMachine* tests if I can get the cross compilers to build them.
I would be very interested in the numbers.
and 2) can someone help me understand what I did wrong in setting up this test?
Difficult to say. Could you build with bjam and repeat the test?
I followed the instructions to build the examples. Changed to the example directory and ran <<bjam "sTOOLS=gcc">>. I got lazy and only ran the PingPong* progs. Guess I should have mentioned that. %>]
Oh, sorry. The fact that you saw the warnings led me to believe that the examples weren't built with bjam.
Any chance that, in the absence of some future evidence to the contrary, those dtorS can be made virtual in the library?
I'm at least reluctant to do that. Given the abundance of platforms that support C++ we can never be sure that there is not one where performance will suffer significantly when the dtors are made virtual. From the 3 compilers I use GCC is the only one that a) has such a non-virtual dtor warning *and* b) doesn't have a pragma to turn off warnings. Hopefully, the latter will soon be taken care of... Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber wrote:
I'm at least reluctant to do that. Given the abundance of platforms that support C++ we can never be sure that there is not one where performance will suffer significantly when the dtors are made virtual. From the 3 compilers I use GCC is the only one that a) has such a non-virtual dtor warning *and* b) doesn't have a pragma to turn off warnings. Hopefully, the latter will soon be taken care of...
GCC does have -Wno-non-virtual-dtor to disable the warning. There's also a project underway to enable much finer-grained control of warnings. jon
Jonathan Wakely wrote:
Andreas Huber wrote:
I'm at least reluctant to do that. Given the abundance of platforms that support C++ we can never be sure that there is not one where performance will suffer significantly when the dtors are made virtual. From the 3 compilers I use GCC is the only one that a) has such a non-virtual dtor warning *and* b) doesn't have a pragma to turn off warnings. Hopefully, the latter will soon be taken care of...
GCC does have -Wno-non-virtual-dtor to disable the warning.
But it doesn't have a way to leave the warning on for the useful cases and disable it when it's useless (when the destructor is protected, for instance.) :-)
Hi Jonathan Jonathan Wakely wrote:
Andreas Huber wrote:
I'm at least reluctant to do that. Given the abundance of platforms that support C++ we can never be sure that there is not one where performance will suffer significantly when the dtors are made virtual. From the 3 compilers I use GCC is the only one that a) has such a non-virtual dtor warning *and* b) doesn't have a pragma to turn off warnings. Hopefully, the latter will soon be taken care of...
GCC does have -Wno-non-virtual-dtor to disable the warning.
Yes, I know that (and I'm using it to turn off that warning for bjam-built stuff). What I meant is that there currently is no way to do that in a hpp or cpp file. E.g. on Intel you can write: #pragma warning( disable: 444 ) // destructor for base is not virtual
There's also a project underway to enable much finer-grained control of warnings.
That's good to hear. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber wrote:
Jonathan Wakely wrote:
There's also a project underway to enable much finer-grained control of warnings.
That's good to hear.
Hi, re-reading http://gcc.gnu.org/wiki/Warning%20Message%20Control I see that only "limited #pragma support" is planned, so maybe I spoke too soon. It might be that non-virtual dtors are one of the places it will be supported, as it's something you can know is safe and want to disable locally. jon
participants (4)
-
Andreas Huber -
BRIDGES Dick -
Jonathan Wakely -
Peter Dimov