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

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 wrote:

On Mon, Oct 12, 2009 at 20:18, Steven Watanabe wrote:

...

AMDG

Peter Soetens wrote:

...

On Wed, Sep 30, 2009 at 20:48, Steven Watanabe 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users