Re: [boost] [statechart] Problems if I make dtorS virtual?

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-08-30 10:25:08

BRIDGES Dick <Dick.Bridges <at> us.thalesgroup.com> writes:
> > Ugh, yet another policy or #define? I'd want to avoid that. Since this
> > is gcc-only problem, I think the best I can do is to make that
> > destructor virtual for gcc and leave it non-virtual for all other
> > compilers.
> > 
> > Thoughts?
> 
> My $.02 says to leave the destructor non-virtual across the board and
> I sell -Wno-non-vitual-dtor to my QA group.  Otherwise some embedded
> device will show up that favors non-virtual and I'll be the one asking
> you to put it back so our gcc-based cross-compilers can use it. ;)

Noted. FWIW, I'm currently in the process of optimizing state-entry & state-
exit. One *side-effect* of this could be that the destructor will be made 
virtual anyway, see below...

> That and the threat of a #define. %-P

I would prefer to avoid the noise of introducing a #define that is only useful 
for one compiler and might well cease to have an effect in the near future. 
If, after completing state-entry and state-exit optimization the dtor isn't 
virtual anyway and we find that making it virtual can indeed degrade 
performance significantly then I think it is time to introduce that #define.

For the moment I would recommend that you modify the library code to suit your 
needs. Luckily, you only need to modify state_base.hpp for this purpose (all 
other state classes directly or indirectly inherit from state_base, which 
ensures that their destructors end up being virtual even when they are not 
declared so). Hope that's ok for you...

Regards,

--
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.