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: Peter Soetens (peter.soetens_at_[hidden])
Date: 2009-10-12 16:05:59

On Mon, Oct 12, 2009 at 20:18, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> 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...

Which I must have missed. What better fix has been confirmed to solve
this problem ?

>
>> 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.

I'm not sure what you're aiming at (my understanding or yours), but
this is not an argument. What we do know is that making the destructor
virtual and dropping the cast will produce the correct behavior for
virtually every C++ compiler out there.

Peter