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: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-10-12 16:18:49

Couldn't we just use shared_ptr to manage the object? That won't need
a virtual destructor and in all likelihood will work fine since we
don't have similar bug reports for shared_ptr.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

On Mon, Oct 12, 2009 at 1:05 PM, Peter Soetens <peter.soetens_at_[hidden]> wrote:
> 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
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users