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

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andreas Huber Sent: Thursday, August 25, 2005 9:14 AM To: boost@lists.boost.org Subject: Re: [boost] [statechart] Problems if I make dtorS virtual?
BRIDGES Dick wrote:
I followed the instructions to build the examples. Changed to the example directory and ran <<bjam "sTOOLS=gcc">>. I got lazy and only ran the PingPong* progs. Guess I should have mentioned that. %>]
Oh, sorry. The fact that you saw the warnings led me to believe that
[snip] the
examples weren't built with bjam.
Any chance that, in the absence of some future evidence to the contrary, those dtorS can be made virtual in the library?
I'm at least reluctant to do that. Given the abundance of platforms
support C++ we can never be sure that there is not one where
will suffer significantly when the dtors are made virtual. From the 3 compilers I use GCC is the only one that a) has such a non-virtual
Again my exposition was lacking. I built my code and the examples with both bjam and make in unsuccessful attempts to get myself out from between this rock (warnings,warnings everywhere) and that hard place (convincing QA that setting the -Wno-non-virtual-dtor flag for *ALL* of our code that touches the library is acceptable). that performance dtor
warning *and* b) doesn't have a pragma to turn off warnings. Hopefully, the latter will soon be taken care of...
I understand. Balancing performance and safety in this dynamic environment of promises and deadlines must be very difficult. I envy your ability and admire what you've accomplished. Just a thought - might it be worthwhile to introduce a policy to allow the user to choose between maximum performance and the comforting consistency of virtual dtorS to go with those virtual functions? :-)
Regards,
-- Andreas Huber
Regards, Dick Bridges

BRIDGES Dick wrote:
Just a thought - might it be worthwhile to introduce a policy to allow the user to choose between maximum performance and the comforting consistency of virtual dtorS to go with those virtual functions? :-)
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? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber
-
BRIDGES Dick