Re: [Boost-users] [test] Malloc exceptions when using test framework on 64bit OS X 10.6.1

Subject: Re: [Boost-users] [test] Malloc exceptions when using test framework on 64bit OS X 10.6.1
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-10-12 14:18:54

AMDG

Peter Soetens wrote:
> On Wed, Sep 30, 2009 at 20:48, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>   
>> Rush Manbert wrote:
>>     
>>> I see your point, but by not using the pointer polymorphically to delete
>>> the derived class objects, you now need to write a workaround for how some
>>> compilers are implemented. But if the base class destructor were virtual,
>>> the delete would be guaranteed to work by the language definition,
>>> regardless of the compiler implementation. You wouldn't care how the
>>> compiler implemented it, it would just work. And it will still just work as
>>> compilers and runtime libraries for C++ evolve. That seems to make more
>>> sense to me.
>>>       
>> As Gennadiy has already said, the fact that making the destructor
>> virtual fixes the problem is an artifact of the way that compilers
>> implement virtual destructors.
>>     
>
> Great! I can point to 10000 lines of code in Boost that accommodate
> for compiler quirks, especially for MSVS and Borland compilers. So for
> once, do the GNU people the same honor and fix this single line of
> code for our automated testing happiness.
>   

Compiler specific workarounds should only be used when
we're dealing with compiler bugs or compiler specific features.
This is neither.

> I don't see any reason here why it shouldn't be fixed for the GNU
> compiler, giving the portability/non-discriminality that Boost claims
> to have over all compilers.
>   

Because there's a better fix that guarantees that it will work
correctly on all compilers...

> Just #ifdef the virtual around the destructor for GNU compilers and we
> can all happily carry on.
>   

IMO, it's a bad idea to throw in a hack to
fix a problem without understanding why it works.

In Christ,
Steven Watanabe