free causes exception

ZombineDev via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Jan 26 14:00:00 PST 2016


On Tuesday, 26 January 2016 at 21:23:28 UTC, Igor wrote:
> On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven 
> Schveighoffer wrote:
>> On 1/26/16 9:20 AM, Igor wrote:
>>> [...]
>>
>> Don't do it in the destructor.
>>
>> I can only imagine that you are triggering the destructor with 
>> destroy? In this case, destroy is calling the destructor, but 
>> then tries to zero the memory (which has already been freed).
>>
>> There is a mechanism D supports (but I believe is deprecated) 
>> by overriding new and delete. You may want to try that. It's 
>> deprecated, but has been for years and years, and I doubt it's 
>> going away any time soon.
>>
>> A class shouldn't care how it's allocated or destroyed. That 
>> is for the memory manager to worry about.
>
> um? Memory manager? I am doing it manually C++ style so I don't 
> have to worry about the god forsaken memory manager. Why is it 
> so difficult? I create the object and release it when I need to.
>
> I can replace the destroy(f) with free(inline the code) but I 
> don't see why that should matter. The whole point of 
> destructors is to do this sort of stuff. That's why they were 
> invented in the first place!?!

Destructors are meant to destroy the members of the object, not 
the object itself. An object should be freed by the destructor of 
its owner and so on, transitively.
A class should not have a hard coded dependency on malloc/free, 
or the GC. You should strive to design it in such a way that the 
clients of the class are free to decide how to manage its memory.


More information about the Digitalmars-d-learn mailing list