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.