is struct delete deterministic? (cf used in Unique)

[Timothee Cour via Digitalmars-d-learn]

On Sun, Mar 8, 2015 at 4:36 AM, Jonathan M Davis via Digitalmars-d-learn <
digitalmars-d-learn at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20150308/0ffdd5c2/attachment.html>