Boost logo

Boost :

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

BRIDGES Dick <Dick.Bridges <at>> 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...


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at