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