|
Boost : |
From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-08-26 11:43:06
> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Andreas Huber
> Sent: Thursday, August 25, 2005 9:14 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [statechart] Problems if I make dtorS virtual?
>
> BRIDGES Dick wrote:
[snip]
> > 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
the
> examples weren't built with bjam.
>
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).
> > 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
that
> support C++ we can never be sure that there is not one where
performance
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk