<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 8, 2015 at 4:36 AM, Jonathan M Davis via Digitalmars-d-learn <span dir="ltr"><<a href="mailto:digitalmars-d-learn@puremagic.com" target="_blank">digitalmars-d-learn@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sunday, March 08, 2015 04:13:28 Jonathan M Davis via Digitalmars-d-learn wrote:<br>
> On Saturday, March 07, 2015 17:20:49 Timothee Cour via Digitalmars-d-learn wrote:<br>
> > To clarify, I'm only asking about a struct allocated via new.<br>
> > Unique!T is wrapped around a struct, but it allocates a struct T via 'new',<br>
> > so my question still holds: does 'delete t' (where t is a struct allocated<br>
> > via new) guarantee deterministic destruction?<br>
> ><br>
> > I'm guessing yes, otherwise Unique would be broken, but where is that<br>
> > specified in the docs?<br>
> > And if delete is to be deprecated (according to the docs), what is the<br>
> > correct way to do that (despite fact that Unique relies on delete).<br>
><br>
> Yes, delete is deterministic. It's basically the same as what you get in C++<br>
> except that it's using the GC heap and therefore is not safe. delete is<br>
> supposed to have been deprecated but has not been yet (mostly because no one<br>
> has gotten around to doing it).<br>
><br>
> If you're using the GC heap and want to destroy an object, that's what<br>
> destroy is for - but it doesn't free the memory, because that's not safe.<br>
> You can free the memory with core.memory.GC.free, but you have to have<br>
> destroyed the object first, since free just frees memory. But that's just<br>
> duplicating what delete does, so it's still unsafe.<br>
><br>
> What's generally considered the correct way to deal with manual memory<br>
> management involves allocating using C's malloc, constructing via emplace,<br>
> and then using destroy and C's free to destroy the object and free its<br>
> memory when you're done. But that's way more of a pain then using new and<br>
> then delete, which is probably part of why some folks still use delete (in<br>
> the case of Unique though, I expect that it's just because it's been around<br>
> a while). Hopefully, the standard allocator stuff will make it as simple as<br>
> using new and delete though - e.g. something like<br>
><br>
> auto ptr = alloc.make!Myobj(arg1, arg2);<br>
> alloc.free(ptr);<br>
><br>
> but the standard allocator stuff isn't currently far enough along yet for us<br>
> to be at that point unfortunately.<br>
<br>
</div></div>I would point out though that until recently, the GC never ran the<br>
destructors for structs on the heap, because it didn't have the type<br>
information to do it. So, if you did<br>
<br>
auto s = new MyStruct;<br>
<br>
its destructor never ran, even if the GC collected it (which it's not<br>
guaranteed to do with any memory). But I don't know if the destructor was<br>
run if you expliictly called delete on the pointer to the struct.<br></blockquote><div><br></div><div>Thanks for you answers, however this last sentence worries me. According to it there's no guarantee then?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, there has recently been work done to make it so that struct<br>
destructors on the heap _are_ run when a struct is collected by the GC, so<br>
the situation there is improving, and if delete didn't call the destructor<br>
before, it probably will with the next release.<br>
<br>
- Jonathan M Davis<br>
<br>
</blockquote></div><br></div></div>