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. However, ~state_base() contains the following annotation:

// This destructor is not virtual for performance reasons. The library // ensures that a state object is never deleted through a state_base // pointer but only through a pointer to the most-derived type. ~state_base() {}

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 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 *** GCC 3.4.2 (MinGW) *** PingPongSingle: 1.27 / 1.27 PingPongMulti1: 6.03 / 6.11 PingPongMulti2: 13.20 / 13.27 BitMachineCustom3: 0.32 / 0.30 *** Intel 9.0 *** PingPongSingle: 1.14 / 1.14 PingPongMulti1: 5.38 / 5.43 PingPongMulti2: 12.27 / 12.35 BitMachineCustom3: 0.16 / 0.16 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, line 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 the tested processors, that is. I can't say whether the picture is the same for processors used in the embedded world.

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?

<extra_credit ot=true my_understanding=faulty>

:-), my understanding is non-existent in this area...

With a well-developed pipelined architecture and a reasonably rich set of addressing operations, shouldn't there be little or no difference between direct and indirect access times - given that the bookeeping normally associated with virtual classes has already been paid for? </extra_credit>

I think my numbers make some limited sense. I don't see how the virtual dtor version could actually be faster as your numbers suggest. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.