Alex Rønne Petersen | 24 May 14:21 2012

Destructor nonsense on dlang.org

Hi,

http://dlang.org/class.html#Destructor

"The garbage collector is not guaranteed to run the destructor for all 
unreferenced objects."

What the *hell*? So resources are allowed to arbitrarily leak and the 
programmer has to actually expect this to happen?

I really, really hope that this is a documentation error or early design 
decision that has since been rectified but with lack of documentation 
updates.

--

-- 
Alex Rønne Petersen
alex <at> lycus.org
http://lycus.org

Thor | 24 May 14:33 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen 
wrote:
> Hi,
>
> http://dlang.org/class.html#Destructor
>
> "The garbage collector is not guaranteed to run the destructor 
> for all unreferenced objects."
>
> What the *hell*? So resources are allowed to arbitrarily leak 
> and the programmer has to actually expect this to happen?
>
> I really, really hope that this is a documentation error or 
> early design decision that has since been rectified but with 
> lack of documentation updates.

use "clear", or "scope (exit)" or "structs" or scoped!... etc.

There could always be a false reference... so you cannot depend 
on automatically releasing resources in a class destructor.

Alex Rønne Petersen | 24 May 14:38 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 14:33, Thor wrote:
> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>> Hi,
>>
>> http://dlang.org/class.html#Destructor
>>
>> "The garbage collector is not guaranteed to run the destructor for all
>> unreferenced objects."
>>
>> What the *hell*? So resources are allowed to arbitrarily leak and the
>> programmer has to actually expect this to happen?
>>
>> I really, really hope that this is a documentation error or early
>> design decision that has since been rectified but with lack of
>> documentation updates.
>
> use "clear", or "scope (exit)" or "structs" or scoped!... etc.

I know.

>
> There could always be a false reference... so you cannot depend on
> automatically releasing resources in a class destructor.
>

False pointers have nothing to do with it. The GC should free and 
finalize all objects on shutdown, meaning the finalizer runs *sooner or 
later*. If this is the case (which I do believe it is), then the docs 
are very wrong.

(Continue reading)

Thor | 24 May 14:48 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 12:38:45 UTC, Alex Rønne Petersen 
wrote:
> On 24-05-2012 14:33, Thor wrote:
>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen 
>> wrote:
>>> Hi,
>>>
>>> http://dlang.org/class.html#Destructor
>>>
>>> "The garbage collector is not guaranteed to run the 
>>> destructor for all
>>> unreferenced objects."
>>>
>>> What the *hell*? So resources are allowed to arbitrarily leak 
>>> and the
>>> programmer has to actually expect this to happen?
>>>
>>> I really, really hope that this is a documentation error or 
>>> early
>>> design decision that has since been rectified but with lack of
>>> documentation updates.
>>
>> use "clear", or "scope (exit)" or "structs" or scoped!... etc.
>
> I know.
>
>>
>> There could always be a false reference... so you cannot 
>> depend on
>> automatically releasing resources in a class destructor.
(Continue reading)

Alex Rønne Petersen | 24 May 16:28 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 14:48, Thor wrote:
> On Thursday, 24 May 2012 at 12:38:45 UTC, Alex Rønne Petersen wrote:
>> On 24-05-2012 14:33, Thor wrote:
>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>> Hi,
>>>>
>>>> http://dlang.org/class.html#Destructor
>>>>
>>>> "The garbage collector is not guaranteed to run the destructor for all
>>>> unreferenced objects."
>>>>
>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>> programmer has to actually expect this to happen?
>>>>
>>>> I really, really hope that this is a documentation error or early
>>>> design decision that has since been rectified but with lack of
>>>> documentation updates.
>>>
>>> use "clear", or "scope (exit)" or "structs" or scoped!... etc.
>>
>> I know.
>>
>>>
>>> There could always be a false reference... so you cannot depend on
>>> automatically releasing resources in a class destructor.
>>>
>>
>> False pointers have nothing to do with it. The GC should free and
>> finalize all objects on shutdown, meaning the finalizer runs *sooner
>> or later*. If this is the case (which I do believe it is), then the
(Continue reading)

Andrei Alexandrescu | 24 May 16:54 2012

Re: Destructor nonsense on dlang.org

On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
> The GC should (and probably does) assume at shutdown that all objects
> are unreferenced, and therefore reclaim and finalize them.

They may refer to one another.

Andrei

Alex Rønne Petersen | 24 May 16:57 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 16:54, Andrei Alexandrescu wrote:
> On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
>> The GC should (and probably does) assume at shutdown that all objects
>> are unreferenced, and therefore reclaim and finalize them.
>
> They may refer to one another.
>
> Andrei
>

Doesn't matter: Nothing is guaranteed about order of finalization (and 
this is reasonable). Thus, the finalizers can be run in any arbitrary 
order. The important point here is that they are run *at all*.

--

-- 
Alex Rønne Petersen
alex <at> lycus.org
http://lycus.org

Andrei Alexandrescu | 24 May 18:06 2012

Re: Destructor nonsense on dlang.org

On 5/24/12 9:57 AM, Alex Rønne Petersen wrote:
> On 24-05-2012 16:54, Andrei Alexandrescu wrote:
>> On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
>>> The GC should (and probably does) assume at shutdown that all objects
>>> are unreferenced, and therefore reclaim and finalize them.
>>
>> They may refer to one another.
>>
>> Andrei
>>
>
> Doesn't matter: Nothing is guaranteed about order of finalization (and
> this is reasonable). Thus, the finalizers can be run in any arbitrary
> order. The important point here is that they are run *at all*.

It does matter because a destructor may use an object that has just been 
destroyed.

Andrei

Alex Rønne Petersen | 24 May 18:10 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 18:06, Andrei Alexandrescu wrote:
> On 5/24/12 9:57 AM, Alex Rønne Petersen wrote:
>> On 24-05-2012 16:54, Andrei Alexandrescu wrote:
>>> On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
>>>> The GC should (and probably does) assume at shutdown that all objects
>>>> are unreferenced, and therefore reclaim and finalize them.
>>>
>>> They may refer to one another.
>>>
>>> Andrei
>>>
>>
>> Doesn't matter: Nothing is guaranteed about order of finalization (and
>> this is reasonable). Thus, the finalizers can be run in any arbitrary
>> order. The important point here is that they are run *at all*.
>
> It does matter because a destructor may use an object that has just been
> destroyed.
>
> Andrei
>

No, the docs specifically state that this is invalid (and it currently 
throws InvalidMemoryOperationError in most cases).

Whether it *should* be allowed is arguable, but it isn't currently, both 
in docs and impl.

--

-- 
Alex Rønne Petersen
(Continue reading)

ponce | 24 May 19:06 2012

Re: Destructor nonsense on dlang.org

Le 24/05/2012 18:10, Alex Rønne Petersen a écrit :
> On 24-05-2012 18:06, Andrei Alexandrescu wrote:
>> It does matter because a destructor may use an object that has just been
>> destroyed.
>>
>> Andrei
>>
>
> No, the docs specifically state that this is invalid (and it currently
> throws InvalidMemoryOperationError in most cases).
>
> Whether it *should* be allowed is arguable, but it isn't currently, both
> in docs and impl.
>

I really had a hard time to believe it when #D told me so, but there is 
no guaranteed order of destruction and as you cannot relies on members 
still being alive in a class destructor.
All of it can happen when making absolutely no cycles in the object graph.

What I do now is having a close function for each class which hold a 
non-memory resource.

This is writtent in TDPL, but I wish I was told earlier :)

Tove | 24 May 19:47 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 17:06:19 UTC, ponce wrote:
> I really had a hard time to believe it when #D told me so, but 
> there is no guaranteed order of destruction and as you cannot 
> relies on members still being alive in a class destructor.
> All of it can happen when making absolutely no cycles in the 
> object graph.
>
> What I do now is having a close function for each class which 
> hold a non-memory resource.
>
> This is writtent in TDPL, but I wish I was told earlier :)

http://dlang.org/class.html#destructors

"This rule does not apply to auto objects or objects deleted with 
the DeleteExpression, as the destructor is not being run by the 
garbage collector, meaning all references are valid."

i.e. non gc resources are fine... and it's also fine if you call 
clear()... it's only a problem if you rely on automatic 
collection and reference a object... so there's no need for 
close, as clear() will do the trick.

Alex Rønne Petersen | 24 May 19:55 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 19:47, Tove wrote:
> On Thursday, 24 May 2012 at 17:06:19 UTC, ponce wrote:
>> I really had a hard time to believe it when #D told me so, but there
>> is no guaranteed order of destruction and as you cannot relies on
>> members still being alive in a class destructor.
>> All of it can happen when making absolutely no cycles in the object
>> graph.
>>
>> What I do now is having a close function for each class which hold a
>> non-memory resource.
>>
>> This is writtent in TDPL, but I wish I was told earlier :)
>
> http://dlang.org/class.html#destructors
>
> "This rule does not apply to auto objects or objects deleted with the
> DeleteExpression, as the destructor is not being run by the garbage
> collector, meaning all references are valid."
>
> i.e. non gc resources are fine... and it's also fine if you call
> clear()... it's only a problem if you rely on automatic collection and
> reference a object... so there's no need for close, as clear() will do
> the trick.
>
>

I would strongly advise against that, because a missed clear() means 
your finalizer may be run by the runtime's finalization machinery, and 
thus invalidate any invariants you were relying on in the finalizer.

(Continue reading)

David Nadlinger | 24 May 19:55 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 17:55:02 UTC, Alex Rønne Petersen 
wrote:
> I would strongly advise against that, because a missed clear() 
> means your finalizer may be run by the runtime's finalization 
> machinery, and thus invalidate any invariants you were relying 
> on in the finalizer.

Yes – the »correc†

David Nadlinger | 24 May 19:59 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 17:55:02 UTC, Alex Rønne Petersen 
wrote:
> I would strongly advise against that, because a missed clear() 
> means your finalizer may be run by the runtime's finalization 
> machinery, and thus invalidate any invariants you were relying 
> on in the finalizer.

Yes – the »correct« way to handle situations where you need 
deterministic finalization is to use structs on the stack, 
possibly in conjunction with reference counting. Of course, there 
are some situations (e.g. when there are cycles) where this 
doesn't work, but at least it covers most of the »external 
non-memory resource« cases.

Composability can still be a problem, though, because holding a 
reference in a (GC-managed) class object might leave you with 
exactly the same problem you tried to avoid in the first place.

David

Steven Schveighoffer | 24 May 19:57 2012
Picon

Re: Destructor nonsense on dlang.org

On Thu, 24 May 2012 13:47:31 -0400, Tove <tove <at> fransson.se> wrote:

> On Thursday, 24 May 2012 at 17:06:19 UTC, ponce wrote:
>> I really had a hard time to believe it when #D told me so, but there is  
>> no guaranteed order of destruction and as you cannot relies on members  
>> still being alive in a class destructor.
>> All of it can happen when making absolutely no cycles in the object  
>> graph.
>>
>> What I do now is having a close function for each class which hold a  
>> non-memory resource.
>>
>> This is writtent in TDPL, but I wish I was told earlier :)
>
> http://dlang.org/class.html#destructors
>
> "This rule does not apply to auto objects or objects deleted with the  
> DeleteExpression, as the destructor is not being run by the garbage  
> collector, meaning all references are valid."
>
> i.e. non gc resources are fine... and it's also fine if you call  
> clear()... it's only a problem if you rely on automatic collection and  
> reference a object... so there's no need for close, as clear() will do  
> the trick.

There's a big problem with this though.  Your destructor *has no idea*  
whether it's being called from within a collection cycle, or from clear.   
You must assume the most restrictive environment, i.e. that the dtor is  
being called from the GC.

(Continue reading)

Tove | 24 May 20:46 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 17:57:11 UTC, Steven Schveighoffer 
wrote:
> On Thu, 24 May 2012 13:47:31 -0400, Tove <tove <at> fransson.se> 
> wrote:
>
> There's a big problem with this though.  Your destructor *has 
> no idea* whether it's being called from within a collection 
> cycle, or from clear.  You must assume the most restrictive 
> environment, i.e. that the dtor is being called from the GC.
>
> This is even true with struct dtors!
>
> -Steve

If there is a clear location where a manual close() function can 
be called... then there are many safe solutions to automatically 
and safely call clear instead.

std.typecons.Unique

If you are a library creator, you could even use a factory to 
enforce wrapping in Unique...  But I don't see any point of 
adding a non standard destructor function name, there are 
numerous ways to facilitate RAII.

foobar | 24 May 21:46 2012

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 17:57:11 UTC, Steven Schveighoffer 
wrote:
> On Thu, 24 May 2012 13:47:31 -0400, Tove <tove <at> fransson.se> 
> wrote:
>
>> On Thursday, 24 May 2012 at 17:06:19 UTC, ponce wrote:
>>> I really had a hard time to believe it when #D told me so, 
>>> but there is no guaranteed order of destruction and as you 
>>> cannot relies on members still being alive in a class 
>>> destructor.
>>> All of it can happen when making absolutely no cycles in the 
>>> object graph.
>>>
>>> What I do now is having a close function for each class which 
>>> hold a non-memory resource.
>>>
>>> This is writtent in TDPL, but I wish I was told earlier :)
>>
>> http://dlang.org/class.html#destructors
>>
>> "This rule does not apply to auto objects or objects deleted 
>> with the DeleteExpression, as the destructor is not being run 
>> by the garbage collector, meaning all references are valid."
>>
>> i.e. non gc resources are fine... and it's also fine if you 
>> call clear()... it's only a problem if you rely on automatic 
>> collection and reference a object... so there's no need for 
>> close, as clear() will do the trick.
>
> There's a big problem with this though.  Your destructor *has 
(Continue reading)

Tove | 24 May 22:53 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 19:46:07 UTC, foobar wrote:
> Looks to me like an issue with separation of concerns. I think 
> that dtors need to only provide deterministic management of 
> resources and not affect GC algorithms:
> 1. classes should *not* have dtors at all.
> 2. struct values should *not* be gc managed [*].
>

Why not simply set "BlkAttr.NO_SCAN" on ourselves if we need 
certain resources in the destructor? Assuming we one day get user 
defined attributes, it can be make quite simple...

Tove | 25 May 00:49 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 20:53:33 UTC, Tove wrote:
> On Thursday, 24 May 2012 at 19:46:07 UTC, foobar wrote:
>> Looks to me like an issue with separation of concerns. I think 
>> that dtors need to only provide deterministic management of 
>> resources and not affect GC algorithms:
>> 1. classes should *not* have dtors at all.
>> 2. struct values should *not* be gc managed [*].
>>
>
> Why not simply set "BlkAttr.NO_SCAN" on ourselves if we need 
> certain resources in the destructor? Assuming we one day get 
> user defined attributes, it can be make quite simple...

Tested my idea... unfortunately it's broken...

GC.collect() while the program is running, is OK... so I was 
hoping to add:
GC.disable() just before main() ends, but apparently this request 
is ignored.

i.e. back to square 1, undefined collecting order once the 
program exits.

import std.stdio;
import core.memory;

class Important
{
   this()
   {
(Continue reading)

Jacob Carlborg | 25 May 09:13 2012

Re: Destructor nonsense on dlang.org

On 2012-05-24 21:46, foobar wrote:

> Looks to me like an issue with separation of concerns. I think that
> dtors need to only provide deterministic management of resources and not
> affect GC algorithms:
> 1. classes should *not* have dtors at all.
> 2. struct values should *not* be gc managed [*].
>
> Composition of classes and structs should be handled as follows:
> 1. If a class contains a pointer to a struct it doesn't scan it in a GC
> cycle. The runtime can provide a hook so that structs could register a
> callback for RC purposes.
> 2. When a class contains a strcut value, they share the same lifetime
> thus the GC will call the struct's dtor when the object is collected.

How is that any different than having destructors for classes.

--

-- 
/Jacob Carlborg

foobar | 25 May 11:02 2012

Re: Destructor nonsense on dlang.org

On Friday, 25 May 2012 at 07:13:11 UTC, Jacob Carlborg wrote:
> On 2012-05-24 21:46, foobar wrote:
>
>> Looks to me like an issue with separation of concerns. I think 
>> that
>> dtors need to only provide deterministic management of 
>> resources and not
>> affect GC algorithms:
>> 1. classes should *not* have dtors at all.
>> 2. struct values should *not* be gc managed [*].
>>
>> Composition of classes and structs should be handled as 
>> follows:
>> 1. If a class contains a pointer to a struct it doesn't scan 
>> it in a GC
>> cycle. The runtime can provide a hook so that structs could 
>> register a
>> callback for RC purposes.
>> 2. When a class contains a strcut value, they share the same 
>> lifetime
>> thus the GC will call the struct's dtor when the object is 
>> collected.
>
> How is that any different than having destructors for classes.

It makes the call order deterministic like in C++.

e.g.
class Foo {}

(Continue reading)

Jacob Carlborg | 25 May 13:23 2012

Re: Destructor nonsense on dlang.org

On 2012-05-25 11:02, foobar wrote:

> It makes the call order deterministic like in C++.
>
> e.g.
> class Foo {}
>
> struct A {
> resource r;
> ~this() { release(r); }
> }
>
> struct B {
> A* a;
> Foo foo;
> ~this() { delete a; } // [1]
> }

I though we were talking about classes holding structs:

class B {
     A* a;
     Foo foo;
     ~this() { delete a; }
}

In this case you don't know when/if the destructor of B is called. It 
doesn't help to wrap it in a struct, you could just have put it directly 
in A. Is that correct?

(Continue reading)

foobar | 25 May 14:05 2012

Re: Destructor nonsense on dlang.org

On Friday, 25 May 2012 at 11:23:40 UTC, Jacob Carlborg wrote:
> On 2012-05-25 11:02, foobar wrote:
>
>> It makes the call order deterministic like in C++.
>>
>> e.g.
>> class Foo {}
>>
>> struct A {
>> resource r;
>> ~this() { release(r); }
>> }
>>
>> struct B {
>> A* a;
>> Foo foo;
>> ~this() { delete a; } // [1]
>> }
>
> I though we were talking about classes holding structs:
>
> class B {
>     A* a;
>     Foo foo;
>     ~this() { delete a; }
> }
>
> In this case you don't know when/if the destructor of B is 
> called. It doesn't help to wrap it in a struct, you could just 
> have put it directly in A. Is that correct?
(Continue reading)

Jacob Carlborg | 26 May 13:35 2012

Re: Destructor nonsense on dlang.org

On 2012-05-25 14:05, foobar wrote:

>> If you have a pointer to a struct you don't know how it was created.
>> It's possible it's been created with "new", which means the garbage
>> collector needs to delete it.
>
> let's say we add two classes:
> class FooA {
> A a;
> }
> class FooPA {
> A* pa;
> }
>
> For the first case, both the class and the struct share the same
> lifetime thus when an instance of FooA is GC-ed, the GC would call A's
> d-tor and allow it to do what-ever (self) cleaning it requires. This
> means the d-tor will always be called.

Is that the cases even if the destructor of FooA isn't called?

> For the second case, The GC will only scan "pa" to find inner class
> instances but will *not* handle the struct value itself.
> In order to clean what "pa" points to, you need to explicitly call the
> destructor yourself.

Are you saying that the GC won't collect a struct allocated with "new"?

http://dlang.org/expression.html#NewExpression

(Continue reading)

foobar | 26 May 14:28 2012

Re: Destructor nonsense on dlang.org

On Saturday, 26 May 2012 at 11:35:29 UTC, Jacob Carlborg wrote:
> On 2012-05-25 14:05, foobar wrote:
>
>>> If you have a pointer to a struct you don't know how it was 
>>> created.
>>> It's possible it's been created with "new", which means the 
>>> garbage
>>> collector needs to delete it.
>>
>> let's say we add two classes:
>> class FooA {
>> A a;
>> }
>> class FooPA {
>> A* pa;
>> }
>>
>> For the first case, both the class and the struct share the 
>> same
>> lifetime thus when an instance of FooA is GC-ed, the GC would 
>> call A's
>> d-tor and allow it to do what-ever (self) cleaning it 
>> requires. This
>> means the d-tor will always be called.
>
> Is that the cases even if the destructor of FooA isn't called?

Huh? In my model FooA has no destructor.

>
(Continue reading)

Jacob Carlborg | 26 May 17:36 2012

Re: Destructor nonsense on dlang.org

On 2012-05-26 14:28, foobar wrote:

> Huh? In my model FooA has no destructor.

Hm, right. But if a destructor of a class isn't guaranteed to be called, 
how can it guarantee that the struct's destructor will be called?

> I indeed propose that structs allocated with "new" will be put in region
> of the heap *not* managed by the GC. It's a tiny price to pay to get
> more orthogonal semantics which are easier to reason about.
> Please note that this only affects code that directly uses pointers
> which is not common in D and is geared towards more advanced use cases
> where the programmer will likely want to manage the memory explicitly
> anyway.

I see.

--

-- 
/Jacob Carlborg

Artur Skawina | 26 May 14:39 2012
Picon

Re: Destructor nonsense on dlang.org

On 05/26/12 13:35, Jacob Carlborg wrote:
> On 2012-05-25 14:05, foobar wrote:
> 
>>> If you have a pointer to a struct you don't know how it was created.
>>> It's possible it's been created with "new", which means the garbage
>>> collector needs to delete it.
>>
>> let's say we add two classes:
>> class FooA {
>> A a;
>> }
>> class FooPA {
>> A* pa;
>> }
>>
>> For the first case, both the class and the struct share the same
>> lifetime thus when an instance of FooA is GC-ed, the GC would call A's
>> d-tor and allow it to do what-ever (self) cleaning it requires. This
>> means the d-tor will always be called.
> 
> Is that the cases even if the destructor of FooA isn't called?
> 
>> For the second case, The GC will only scan "pa" to find inner class
>> instances but will *not* handle the struct value itself.
>> In order to clean what "pa" points to, you need to explicitly call the
>> destructor yourself.
> 
> Are you saying that the GC won't collect a struct allocated with "new"?
> 
> http://dlang.org/expression.html#NewExpression
(Continue reading)

Regan Heath | 25 May 11:21 2012
Picon

Re: Destructor nonsense on dlang.org

On Thu, 24 May 2012 18:57:11 +0100, Steven Schveighoffer  
<schveiguy <at> yahoo.com> wrote:
> On Thu, 24 May 2012 13:47:31 -0400, Tove <tove <at> fransson.se> wrote:
>
>> On Thursday, 24 May 2012 at 17:06:19 UTC, ponce wrote:
>>> I really had a hard time to believe it when #D told me so, but there  
>>> is no guaranteed order of destruction and as you cannot relies on  
>>> members still being alive in a class destructor.
>>> All of it can happen when making absolutely no cycles in the object  
>>> graph.
>>>
>>> What I do now is having a close function for each class which hold a  
>>> non-memory resource.
>>>
>>> This is writtent in TDPL, but I wish I was told earlier :)
>>
>> http://dlang.org/class.html#destructors
>>
>> "This rule does not apply to auto objects or objects deleted with the  
>> DeleteExpression, as the destructor is not being run by the garbage  
>> collector, meaning all references are valid."
>>
>> i.e. non gc resources are fine... and it's also fine if you call  
>> clear()... it's only a problem if you rely on automatic collection and  
>> reference a object... so there's no need for close, as clear() will do  
>> the trick.
>
> There's a big problem with this though.  Your destructor *has no idea*  
> whether it's being called from within a collection cycle, or from  
> clear.  You must assume the most restrictive environment, i.e. that the  
(Continue reading)

David Nadlinger | 24 May 18:17 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 16:06:23 UTC, Andrei Alexandrescu 
wrote:
> On 5/24/12 9:57 AM, Alex Rønne Petersen wrote:
>> Doesn't matter: Nothing is guaranteed about order of 
>> finalization (and
>> this is reasonable). Thus, the finalizers can be run in any 
>> arbitrary
>> order. The important point here is that they are run *at all*.
> It does matter because a destructor may use an object that has 
> just been destroyed.

You can't do that in today's D either, going by the spec as well 
by the actual implementation.

David

Mehrdad | 25 May 07:07 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 16:06:23 UTC, Andrei Alexandrescu 
wrote:
> It does matter because a destructor may use an object that has 
> just been destroyed.
>
> Andrei

Andrei: .NET has this exact problem, and handles it pretty well.

There are two types of "Dispose()": manual and automatic.

Whenever you're wrapping some unmanaged resource (e.g. file 
handle), you wrap it inside some managed object (e.g. 
SafeFileHandle).

Then you embed _that_ resource in the actual object you want 
(e.g. FileStream).

Now, there are two ways a FileStream can get destroyed:

1. Through a manual call to FileStream.Dispose(). In this case, 
all embedded objects (e.g. SafeFileHandle) are *guaranteed* to be 
valid, so we simply flush the file and call 
SafeFileHandle.Dispose() to dispose of the managed resources, and 
then dispose of all the unmanaged resources (which are primitive 
fields, guaranteed to be accessible). Furthermore, the object 
suppresses its own finalizer.

2. Through a garbage-collected call to ~FileStream(). In this 
case, the managed resources such as SafeFileHandle will be (or is 
(Continue reading)

Andrei Alexandrescu | 25 May 16:35 2012

Re: Destructor nonsense on dlang.org

On 5/25/12 12:07 AM, Mehrdad wrote:
> Now, there are two ways a FileStream can get destroyed:
>
> 1. Through a manual call to FileStream.Dispose(). In this case, all
> embedded objects (e.g. SafeFileHandle) are *guaranteed* to be valid, so
> we simply flush the file and call SafeFileHandle.Dispose() to dispose of
> the managed resources, and then dispose of all the unmanaged resources
> (which are primitive fields, guaranteed to be accessible). Furthermore,
> the object suppresses its own finalizer.
>
> 2. Through a garbage-collected call to ~FileStream(). In this case, the
> managed resources such as SafeFileHandle will be (or is already)
> destroyed SEPARATELY, and so we do _NOT_ access them. We ONLY dispose of
> the unmanaged resources, if any, and let the managed resources take care
> of themselves.

What happens in C# if an object A that has a field referring to object 
B, and the object B has in turn a field referring to object A? That is:

class C { C another; ~this() { writeln(another.another); } }

void main() {
     auto a = new C;
     auto b = new C;
     a.another = b;
     b.another = a;
}

What happens then? Will the GC nullify references to destroyed objects, 
or will it put them in a zombie state?
(Continue reading)

Michael | 13 Nov 00:13 2013

Re: Destructor nonsense on dlang.org

On Friday, 25 May 2012 at 14:35:58 UTC, Andrei Alexandrescu wrote:
>
> What happens in C# if an object A that has a field referring to 
> object B, and the object B has in turn a field referring to 
> object A? That is:
>
> class C { C another; ~this() { writeln(another.another); } }
>
> void main() {
>     auto a = new C;
>     auto b = new C;
>     a.another = b;
>     b.another = a;
> }
>
> What happens then? Will the GC nullify references to destroyed 
> objects, or will it put them in a zombie state?
>
>
> Thanks,
>
> Andrei

In this case the a and b objects will be collected by GC and 
memory freed.
It's a one of most popular questions about .NET GC. Maybe 
something was changed in .NET >= 4.5.

I have another question: there available a good example of 
idiomatic destructor usage in the D?
(Continue reading)

Alex Rønne Petersen | 25 May 16:38 2012

Re: Destructor nonsense on dlang.org

On 25-05-2012 16:35, Andrei Alexandrescu wrote:
> On 5/25/12 12:07 AM, Mehrdad wrote:
>> Now, there are two ways a FileStream can get destroyed:
>>
>> 1. Through a manual call to FileStream.Dispose(). In this case, all
>> embedded objects (e.g. SafeFileHandle) are *guaranteed* to be valid, so
>> we simply flush the file and call SafeFileHandle.Dispose() to dispose of
>> the managed resources, and then dispose of all the unmanaged resources
>> (which are primitive fields, guaranteed to be accessible). Furthermore,
>> the object suppresses its own finalizer.
>>
>> 2. Through a garbage-collected call to ~FileStream(). In this case, the
>> managed resources such as SafeFileHandle will be (or is already)
>> destroyed SEPARATELY, and so we do _NOT_ access them. We ONLY dispose of
>> the unmanaged resources, if any, and let the managed resources take care
>> of themselves.
>
> What happens in C# if an object A that has a field referring to object
> B, and the object B has in turn a field referring to object A? That is:
>
> class C { C another; ~this() { writeln(another.another); } }
>
> void main() {
> auto a = new C;
> auto b = new C;
> a.another = b;
> b.another = a;
> }
>
> What happens then? Will the GC nullify references to destroyed objects,
(Continue reading)

Mehrdad | 25 May 17:53 2012
Picon

Re: Destructor nonsense on dlang.org

On Friday, 25 May 2012 at 14:38:29 UTC, Alex Rønne Petersen 
wrote:
> This is called resurrection: 
> http://msdn.microsoft.com/en-us/magazine/bb985010.aspx (scroll 
> down to Resurrection)

Ah, yes, you're completely right; I missed this fact. Apparently 
under these conditions, you _can_ resurrect objects, but it's bad 
practice (and unnecessary) in most situations.

 <at> Andrei: The reason this is allowed is that finalization is 
_separate_ from garbage collection in .NET. So an object can be 
finalized and yet still not GC'd. Or its finalizer might be 
suppressed, allowing it to get GC'd directly. This allows for 
many possibilities, although you don't usually need them.

Alex Rønne Petersen | 25 May 18:00 2012

Re: Destructor nonsense on dlang.org

On 25-05-2012 17:53, Mehrdad wrote:
> On Friday, 25 May 2012 at 14:38:29 UTC, Alex Rønne Petersen wrote:
>> This is called resurrection:
>> http://msdn.microsoft.com/en-us/magazine/bb985010.aspx (scroll down to
>> Resurrection)
>
>
>
> Ah, yes, you're completely right; I missed this fact. Apparently under
> these conditions, you _can_ resurrect objects, but it's bad practice
> (and unnecessary) in most situations.
>
>
>  <at> Andrei: The reason this is allowed is that finalization is _separate_
> from garbage collection in .NET. So an object can be finalized and yet
> still not GC'd. Or its finalizer might be suppressed, allowing it to get
> GC'd directly. This allows for many possibilities, although you don't
> usually need them.

This is, in fact, how most GCs other than D's work. :)

--

-- 
Alex Rønne Petersen
alex <at> lycus.org
http://lycus.org

Jonathan M Davis | 25 May 21:30 2012
Picon

Re: Destructor nonsense on dlang.org

On Friday, May 25, 2012 17:53:45 Mehrdad wrote:
>  <at> Andrei: The reason this is allowed is that finalization is
> _separate_ from garbage collection in .NET. So an object can be
> finalized and yet still not GC'd. Or its finalizer might be
> suppressed, allowing it to get GC'd directly. This allows for
> many possibilities, although you don't usually need them.

Finalization _can_ be separate from the GC in D thanks to clear, but it does 
normally occur as part of a collection cycle.

- Jonathan M Davis

Mehrdad | 25 May 17:49 2012
Picon

Re: Destructor nonsense on dlang.org

On Friday, 25 May 2012 at 14:35:58 UTC, Andrei Alexandrescu wrote:
> What happens in C# if an object A that has a field referring to 
> object B, and the object B has in turn a field referring to 
> object A? That is:
> What happens then? Will the GC nullify references to destroyed 
> objects, or will it put them in a zombie state?

Depends.

If it's a _manual_ disposal, everything is fine -- neither is
GC'd yet.

If it's an _automatic_ disposal (a.k.a. garbage collection), then
the cross references must not be used. I believe their contents
are either undefined or null, but in either case, you don't worry
about disposing them because the objects will take care of
themselves.

deadalnix | 26 May 19:47 2012
Picon

Re: Destructor nonsense on dlang.org

Le 25/05/2012 16:35, Andrei Alexandrescu a écrit :
> On 5/25/12 12:07 AM, Mehrdad wrote:
>> Now, there are two ways a FileStream can get destroyed:
>>
>> 1. Through a manual call to FileStream.Dispose(). In this case, all
>> embedded objects (e.g. SafeFileHandle) are *guaranteed* to be valid, so
>> we simply flush the file and call SafeFileHandle.Dispose() to dispose of
>> the managed resources, and then dispose of all the unmanaged resources
>> (which are primitive fields, guaranteed to be accessible). Furthermore,
>> the object suppresses its own finalizer.
>>
>> 2. Through a garbage-collected call to ~FileStream(). In this case, the
>> managed resources such as SafeFileHandle will be (or is already)
>> destroyed SEPARATELY, and so we do _NOT_ access them. We ONLY dispose of
>> the unmanaged resources, if any, and let the managed resources take care
>> of themselves.
>
> What happens in C# if an object A that has a field referring to object
> B, and the object B has in turn a field referring to object A? That is:
>
> class C { C another; ~this() { writeln(another.another); } }
>
> void main() {
> auto a = new C;
> auto b = new C;
> a.another = b;
> b.another = a;
> }
>
> What happens then? Will the GC nullify references to destroyed objects,
(Continue reading)

deadalnix | 24 May 17:27 2012
Picon

Re: Destructor nonsense on dlang.org

Le 24/05/2012 16:54, Andrei Alexandrescu a écrit :
> On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
>> The GC should (and probably does) assume at shutdown that all objects
>> are unreferenced, and therefore reclaim and finalize them.
>
> They may refer to one another.
>
> Andrei
>

So what ?

Each GC passes must, mark object that have to be removed, call finalizer 
on them all, THEN recycle memory.

So « zombie » object can still refer to one another in finalization.

The real problem is resurrection, which should be 100% forbiden and this 
must be enforced by the language (ie, the scopeness of this parameter is 
something important).

Andrei Alexandrescu | 24 May 18:10 2012

Re: Destructor nonsense on dlang.org

On 5/24/12 10:27 AM, deadalnix wrote:
> Le 24/05/2012 16:54, Andrei Alexandrescu a écrit :
>> On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
>>> The GC should (and probably does) assume at shutdown that all objects
>>> are unreferenced, and therefore reclaim and finalize them.
>>
>> They may refer to one another.
>>
>> Andrei
>>
>
> So what ?
>
> Each GC passes must, mark object that have to be removed, call finalizer
> on them all, THEN recycle memory.
>
> So « zombie » object can still refer to one another in finalization.

This is possible but not trivial as the state of zombie objects must be 
properly defined. Often such objects will fail their invariant (a 
reasonable state of a zombie object is with the correct vtable, no 
mutex, and all fields in the pre-constructor state).

> The real problem is resurrection, which should be 100% forbiden and this
> must be enforced by the language (ie, the scopeness of this parameter is
> something important).

As one aspect, calls to new should fail during destruction.

Andrei
(Continue reading)

Alex Rønne Petersen | 24 May 18:12 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 18:10, Andrei Alexandrescu wrote:
> On 5/24/12 10:27 AM, deadalnix wrote:
>> Le 24/05/2012 16:54, Andrei Alexandrescu a écrit :
>>> On 5/24/12 9:28 AM, Alex Rønne Petersen wrote:
>>>> The GC should (and probably does) assume at shutdown that all objects
>>>> are unreferenced, and therefore reclaim and finalize them.
>>>
>>> They may refer to one another.
>>>
>>> Andrei
>>>
>>
>> So what ?
>>
>> Each GC passes must, mark object that have to be removed, call finalizer
>> on them all, THEN recycle memory.
>>
>> So « zombie » object can still refer to one another in finalization.
>
> This is possible but not trivial as the state of zombie objects must be
> properly defined. Often such objects will fail their invariant (a
> reasonable state of a zombie object is with the correct vtable, no
> mutex, and all fields in the pre-constructor state).
>
>> The real problem is resurrection, which should be 100% forbiden and this
>> must be enforced by the language (ie, the scopeness of this parameter is
>> something important).
>
> As one aspect, calls to new should fail during destruction.
>
(Continue reading)

Michel Fortin | 24 May 14:43 2012

Re: Destructor nonsense on dlang.org

On 2012-05-24 12:21:01 +0000, Alex Rønne Petersen <alex <at> lycus.org> said:

> Hi,
> 
> http://dlang.org/class.html#Destructor
> 
> "The garbage collector is not guaranteed to run the destructor for all 
> unreferenced objects."
> 
> What the *hell*? So resources are allowed to arbitrarily leak and the 
> programmer has to actually expect this to happen?
> 
> I really, really hope that this is a documentation error or early 
> design decision that has since been rectified but with lack of 
> documentation updates.

I think it means that objects not collected when the program terminates 
will never be, and thus the destructor will not be called.

There's also the issue of false pointers that can prevent some objects 
from being collected.

More generally, you can't really count on the destructor being called 
because the GC is free to decide when to recycle memory. An 
implementation that never collects and always allocate new memory is a 
perfectly valid GC implementation, even though it might not be very 
practical in most cases.

--

-- 
Michel Fortin
(Continue reading)

Alex Rønne Petersen | 24 May 16:35 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 14:43, Michel Fortin wrote:
> On 2012-05-24 12:21:01 +0000, Alex Rønne Petersen <alex <at> lycus.org> said:
>
>> Hi,
>>
>> http://dlang.org/class.html#Destructor
>>
>> "The garbage collector is not guaranteed to run the destructor for all
>> unreferenced objects."
>>
>> What the *hell*? So resources are allowed to arbitrarily leak and the
>> programmer has to actually expect this to happen?
>>
>> I really, really hope that this is a documentation error or early
>> design decision that has since been rectified but with lack of
>> documentation updates.
>
> I think it means that objects not collected when the program terminates
> will never be, and thus the destructor will not be called.

That's silly. Microsoft .NET and Mono have been running finalizers on 
runtime shutdown for a long time without problems.

>
> There's also the issue of false pointers that can prevent some objects
> from being collected.

Right, but I think if we guarantee finalization at shutdown, that 
shouldn't matter.

(Continue reading)

Michel Fortin | 24 May 17:18 2012

Re: Destructor nonsense on dlang.org

On 2012-05-24 14:35:45 +0000, Alex Rønne Petersen <alex <at> lycus.org> said:

> On 24-05-2012 14:43, Michel Fortin wrote:
>> I think it means that objects not collected when the program terminates
>> will never be, and thus the destructor will not be called.
> 
> That's silly. Microsoft .NET and Mono have been running finalizers on 
> runtime shutdown for a long time without problems.
> 
>> There's also the issue of false pointers that can prevent some objects
>> from being collected.
> 
> Right, but I think if we guarantee finalization at shutdown, that 
> shouldn't matter.

.NET is a virtual machine which has total control of all the code that 
runs. D has to work with the C runtime and other non-D code that might 
use D code more or less directly.

The interesting question is *how* do they do it without causing 
thread-safety issues? Perhaps they wait until all threads have been 
terminated, or perhaps they're unsafe too. Would doing the same be 
appropriate for D? Does this mean we can't use anything using static 
and global variables in destructors because they might have been 
finalized? If so, how does the compiler detects this?

If there's a way and it is not overly costly in performance, it might 
be a good idea. But we're not in a virtual machine, there are more 
constrains we must abide to and we might have to make different 
compromises.
(Continue reading)

Alex Rønne Petersen | 24 May 17:43 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 17:18, Michel Fortin wrote:
> On 2012-05-24 14:35:45 +0000, Alex Rønne Petersen <alex <at> lycus.org> said:
>
>> On 24-05-2012 14:43, Michel Fortin wrote:
>>> I think it means that objects not collected when the program terminates
>>> will never be, and thus the destructor will not be called.
>>
>> That's silly. Microsoft .NET and Mono have been running finalizers on
>> runtime shutdown for a long time without problems.
>>
>>> There's also the issue of false pointers that can prevent some objects
>>> from being collected.
>>
>> Right, but I think if we guarantee finalization at shutdown, that
>> shouldn't matter.
>
> .NET is a virtual machine which has total control of all the code that
> runs. D has to work with the C runtime and other non-D code that might
> use D code more or less directly.

So does .NET. It just does it with some trampoline magic. Non-D code 
just has to call thread_attachThis()/thread_detachThis() and friends.

>
> The interesting question is *how* do they do it without causing
> thread-safety issues? Perhaps they wait until all threads have been
> terminated, or perhaps they're unsafe too. Would doing the same be
> appropriate for D? Does this mean we can't use anything using static and
> global variables in destructors because they might have been finalized?
> If so, how does the compiler detects this?
(Continue reading)

Tove | 24 May 18:02 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 15:43:57 UTC, Alex Rønne Petersen 
wrote:
>
> We just need a dispose pattern whereby explicit dispose() 
> instructs the GC to not finalize.
>
>>
>> So I'm curious, what resource are we trying to free here?
>>
>
> None. I just came across it in the docs and found it completely 
> insane.

Hmm... well, as long as it's optional behavior... as in my case I 
actually want to go in the opposite direction... short-lived tool 
which claims x resources and is run once for every file...

So in this case, resources should be "free:ed" _unless_ it's at 
program termination... as then it just slows down the shutdown 
procedure, the OS reclaim it faster anyway.

Peter Alexander | 24 May 14:54 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen 
wrote:
> Hi,
>
> http://dlang.org/class.html#Destructor
>
> "The garbage collector is not guaranteed to run the destructor 
> for all unreferenced objects."
>
> What the *hell*? So resources are allowed to arbitrarily leak 
> and the programmer has to actually expect this to happen?
>
> I really, really hope that this is a documentation error or 
> early design decision that has since been rectified but with 
> lack of documentation updates.

I'm pretty sure it's the same in Java.

Finalizers (a.k.a. class destructors) are practically useless.

Steven Schveighoffer | 24 May 15:38 2012
Picon

Re: Destructor nonsense on dlang.org

On Thu, 24 May 2012 08:54:45 -0400, Peter Alexander  
<peter.alexander.au <at> gmail.com> wrote:

> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>> Hi,
>>
>> http://dlang.org/class.html#Destructor
>>
>> "The garbage collector is not guaranteed to run the destructor for all  
>> unreferenced objects."
>>
>> What the *hell*? So resources are allowed to arbitrarily leak and the  
>> programmer has to actually expect this to happen?
>>
>> I really, really hope that this is a documentation error or early  
>> design decision that has since been rectified but with lack of  
>> documentation updates.
>
> I'm pretty sure it's the same in Java.
>
> Finalizers (a.k.a. class destructors) are practically useless.

 From Java spec:

"The Java programming language does not specify how soon a finalizer will  
be invoked, except to say that it will happen before the storage for the  
object is reused"

So yeah, there is no guarantee when a finalizer will be invoked.

(Continue reading)

Michel Fortin | 24 May 16:00 2012

Re: Destructor nonsense on dlang.org

On 2012-05-24 13:38:01 +0000, "Steven Schveighoffer" 
<schveiguy <at> yahoo.com> said:

> However, I'd tend to believe Java implementations will attempt to invoke
> all finalizers of objects left on the heap at program shutdown.

In Java you can call System.runFinalizersOnExit(true), but the default 
is false and this method has been deprecated because unsafe in 
multithreaded environments.

<http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#runFinalization()>

--

-- 

Michel Fortin
michel.fortin <at> michelf.com
http://michelf.com/

Alex Rønne Petersen | 24 May 16:37 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 16:00, Michel Fortin wrote:
> On 2012-05-24 13:38:01 +0000, "Steven Schveighoffer"
> <schveiguy <at> yahoo.com> said:
>
>> However, I'd tend to believe Java implementations will attempt to invoke
>> all finalizers of objects left on the heap at program shutdown.
>
> In Java you can call System.runFinalizersOnExit(true), but the default
> is false and this method has been deprecated because unsafe in
> multithreaded environments.
>
> <http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#runFinalization()>
>
>
>

It's only deprecated because Java's way of handling threading and 
finalization is apparently completely broken. See C# and the CLR for a 
system that actually works.

--

-- 
Alex Rønne Petersen
alex <at> lycus.org
http://lycus.org

Russel Winder | 24 May 16:03 2012
Picon

Re: Destructor nonsense on dlang.org

On Thu, 2012-05-24 at 09:38 -0400, Steven Schveighoffer wrote:
[...]
> However, I'd tend to believe Java implementations will attempt to invoke  
> all finalizers of objects left on the heap at program shutdown.

As far as I am aware Java implementations do no finalization on exit
unless System.runFinalizersOnExit(true) has been called. This method is
deprecated since it can cause incorrect finalization. But like all
things Java that have been deprecated, they never actually go away.

There is System.runFinalization() which executes finalize on all objects
in the pending finalization queue.

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel <at> winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Alex Rønne Petersen | 24 May 16:36 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 15:38, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 08:54:45 -0400, Peter Alexander
> <peter.alexander.au <at> gmail.com> wrote:
>
>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>> Hi,
>>>
>>> http://dlang.org/class.html#Destructor
>>>
>>> "The garbage collector is not guaranteed to run the destructor for
>>> all unreferenced objects."
>>>
>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>> programmer has to actually expect this to happen?
>>>
>>> I really, really hope that this is a documentation error or early
>>> design decision that has since been rectified but with lack of
>>> documentation updates.
>>
>> I'm pretty sure it's the same in Java.
>>
>> Finalizers (a.k.a. class destructors) are practically useless.
>
>  From Java spec:
>
> "The Java programming language does not specify how soon a finalizer
> will be invoked, except to say that it will happen before the storage
> for the object is reused"
>
> So yeah, there is no guarantee when a finalizer will be invoked.
(Continue reading)

deadalnix | 24 May 15:47 2012
Picon

Re: Destructor nonsense on dlang.org

Le 24/05/2012 14:54, Peter Alexander a écrit :
> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>> Hi,
>>
>> http://dlang.org/class.html#Destructor
>>
>> "The garbage collector is not guaranteed to run the destructor for all
>> unreferenced objects."
>>
>> What the *hell*? So resources are allowed to arbitrarily leak and the
>> programmer has to actually expect this to happen?
>>
>> I really, really hope that this is a documentation error or early
>> design decision that has since been rectified but with lack of
>> documentation updates.
>
> I'm pretty sure it's the same in Java.
>
> Finalizers (a.k.a. class destructors) are practically useless.

Java finalizer is a pretty bad design decision. Let's not reproduce 
error made in Java in D's destructors.

Steven Schveighoffer | 24 May 15:49 2012
Picon

Re: Destructor nonsense on dlang.org

On Thu, 24 May 2012 09:47:23 -0400, deadalnix <deadalnix <at> gmail.com> wrote:

> Le 24/05/2012 14:54, Peter Alexander a écrit :
>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>> Hi,
>>>
>>> http://dlang.org/class.html#Destructor
>>>
>>> "The garbage collector is not guaranteed to run the destructor for all
>>> unreferenced objects."
>>>
>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>> programmer has to actually expect this to happen?
>>>
>>> I really, really hope that this is a documentation error or early
>>> design decision that has since been rectified but with lack of
>>> documentation updates.
>>
>> I'm pretty sure it's the same in Java.
>>
>> Finalizers (a.k.a. class destructors) are practically useless.
>
> Java finalizer is a pretty bad design decision. Let's not reproduce  
> error made in Java in D's destructors.

You actually need a finalizer if you want to have resources that aren't GC  
allocated.

-Steve

(Continue reading)

Alex Rønne Petersen | 24 May 16:30 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 15:49, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 09:47:23 -0400, deadalnix <deadalnix <at> gmail.com> wrote:
>
>> Le 24/05/2012 14:54, Peter Alexander a écrit :
>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>> Hi,
>>>>
>>>> http://dlang.org/class.html#Destructor
>>>>
>>>> "The garbage collector is not guaranteed to run the destructor for all
>>>> unreferenced objects."
>>>>
>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>> programmer has to actually expect this to happen?
>>>>
>>>> I really, really hope that this is a documentation error or early
>>>> design decision that has since been rectified but with lack of
>>>> documentation updates.
>>>
>>> I'm pretty sure it's the same in Java.
>>>
>>> Finalizers (a.k.a. class destructors) are practically useless.
>>
>> Java finalizer is a pretty bad design decision. Let's not reproduce
>> error made in Java in D's destructors.
>
> You actually need a finalizer if you want to have resources that aren't
> GC allocated.
>
> -Steve
(Continue reading)

Steven Schveighoffer | 24 May 16:53 2012
Picon

Re: Destructor nonsense on dlang.org

On Thu, 24 May 2012 10:30:02 -0400, Alex Rønne Petersen <alex <at> lycus.org>  
wrote:

> On 24-05-2012 15:49, Steven Schveighoffer wrote:
>> On Thu, 24 May 2012 09:47:23 -0400, deadalnix <deadalnix <at> gmail.com>  
>> wrote:
>>
>>> Le 24/05/2012 14:54, Peter Alexander a écrit :
>>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>>> Hi,
>>>>>
>>>>> http://dlang.org/class.html#Destructor
>>>>>
>>>>> "The garbage collector is not guaranteed to run the destructor for  
>>>>> all
>>>>> unreferenced objects."
>>>>>
>>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>>> programmer has to actually expect this to happen?
>>>>>
>>>>> I really, really hope that this is a documentation error or early
>>>>> design decision that has since been rectified but with lack of
>>>>> documentation updates.
>>>>
>>>> I'm pretty sure it's the same in Java.
>>>>
>>>> Finalizers (a.k.a. class destructors) are practically useless.
>>>
>>> Java finalizer is a pretty bad design decision. Let's not reproduce
>>> error made in Java in D's destructors.
(Continue reading)

Alex Rønne Petersen | 24 May 16:56 2012

Re: Destructor nonsense on dlang.org

On 24-05-2012 16:53, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 10:30:02 -0400, Alex Rønne Petersen <alex <at> lycus.org>
> wrote:
>
>> On 24-05-2012 15:49, Steven Schveighoffer wrote:
>>> On Thu, 24 May 2012 09:47:23 -0400, deadalnix <deadalnix <at> gmail.com>
>>> wrote:
>>>
>>>> Le 24/05/2012 14:54, Peter Alexander a écrit :
>>>>> On Thursday, 24 May 2012 at 12:21:02 UTC, Alex Rønne Petersen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> http://dlang.org/class.html#Destructor
>>>>>>
>>>>>> "The garbage collector is not guaranteed to run the destructor for
>>>>>> all
>>>>>> unreferenced objects."
>>>>>>
>>>>>> What the *hell*? So resources are allowed to arbitrarily leak and the
>>>>>> programmer has to actually expect this to happen?
>>>>>>
>>>>>> I really, really hope that this is a documentation error or early
>>>>>> design decision that has since been rectified but with lack of
>>>>>> documentation updates.
>>>>>
>>>>> I'm pretty sure it's the same in Java.
>>>>>
>>>>> Finalizers (a.k.a. class destructors) are practically useless.
>>>>
>>>> Java finalizer is a pretty bad design decision. Let's not reproduce
(Continue reading)

Jacob Carlborg | 24 May 17:04 2012

Re: Destructor nonsense on dlang.org

On 2012-05-24 16:53, Steven Schveighoffer wrote:

> What I think we need is a dispose pattern for objects, like Tango has.

Object.dispose in Tango is called on scope exit if the object is 
variable is declared "scope". "scope" is deprecated in D2.

--

-- 
/Jacob Carlborg

Steven Schveighoffer | 24 May 17:17 2012
Picon

Re: Destructor nonsense on dlang.org

On Thu, 24 May 2012 11:04:06 -0400, Jacob Carlborg <doob <at> me.com> wrote:

> On 2012-05-24 16:53, Steven Schveighoffer wrote:
>
>> What I think we need is a dispose pattern for objects, like Tango has.
>
> Object.dispose in Tango is called on scope exit if the object is  
> variable is declared "scope". "scope" is deprecated in D2.
>

We can easily hook that in object.clear, which any scoped library  
implementation should be calling.

-Steve

David Nadlinger | 24 May 17:17 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 15:04:06 UTC, Jacob Carlborg wrote:
> On 2012-05-24 16:53, Steven Schveighoffer wrote:
>> What I think we need is a dispose pattern for objects, like 
>> Tango has.
>
> Object.dispose in Tango is called on scope exit if the object 
> is variable is declared "scope". "scope" is deprecated in D2.

As for replicating that functionality, Scoped!T could always 
check for a magic dispose() method (maybe with another name, a 
marker parameter, …) and if it exists, call it on destruction.

But of course, the »universality« of the Tango runtimes 
solution is lost with this.

David

deadalnix | 24 May 17:21 2012
Picon

Re: Destructor nonsense on dlang.org

Le 24/05/2012 15:49, Steven Schveighoffer a écrit :
> You actually need a finalizer if you want to have resources that aren't
> GC allocated.
>
> -Steve

Indeed. But java's way of doing it is very poor.

Mehrdad | 25 May 06:23 2012
Picon

Re: Destructor nonsense on dlang.org

On Thursday, 24 May 2012 at 13:49:38 UTC, Steven Schveighoffer 
wrote:
> You actually need a finalizer if you want to have resources 
> that aren't GC allocated.

Does that ring a bell? ;)


Gmane