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