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.