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() {
au
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 fl
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
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:
>>
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 clas
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
On Friday, 25 May 2012 at 19:30:35 UTC, Jonathan M Davis wrote:
On Friday, May 25, 2012 17:53:45 Mehrdad wrote:
@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
On Friday, May 25, 2012 17:53:45 Mehrdad wrote:
> @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 f
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
thes
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 o
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 pu
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
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 di
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 t
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;
On Thu, 24 May 2012 18:57:11 +0100, Steven Schveighoffer
wrote:
On Thu, 24 May 2012 13:47:31 -0400, 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 canno
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 dtor
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 [*].
Compo
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.
Wheneve
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? ;)
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 *no
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
On Thursday, 24 May 2012 at 17:57:11 UTC, Steven Schveighoffer
wrote:
On Thu, 24 May 2012 13:47:31 -0400, 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
On Thursday, 24 May 2012 at 17:57:11 UTC, Steven Schveighoffer
wrote:
On Thu, 24 May 2012 13:47:31 -0400, Tove
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 rest
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 »corr
On Thu, 24 May 2012 13:47:31 -0400, 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
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 »corr
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 whe
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
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 InvalidMemoryOperationEr
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 th
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
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 re
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 anothe
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
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
insa
On 24-05-2012 17:18, Michel Fortin wrote:
On 2012-05-24 14:35:45 +, Alex Rønne Petersen 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. Micros
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
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.
On 2012-05-24 14:35:45 +, Alex Rønne Petersen 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 finaliz
On Thu, 24 May 2012 11:04:06 -0400, 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 depre
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 dep
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
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 g
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
On 24-05-2012 16:53, Steven Schveighoffer wrote:
On Thu, 24 May 2012 10:30:02 -0400, Alex Rønne Petersen
wrote:
On 24-05-2012 15:49, Steven Schveighoffer wrote:
On Thu, 24 May 2012 09:47:23 -0400, deadalnix
wrote:
Le 24/05/2012 14:54, Peter Alexander a écrit :
On Thursday, 24 May 2012 at
On Thu, 24 May 2012 10:30:02 -0400, Alex Rønne Petersen
wrote:
On 24-05-2012 15:49, Steven Schveighoffer wrote:
On Thu, 24 May 2012 09:47:23 -0400, deadalnix
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,
On 24-05-2012 14:43, Michel Fortin wrote:
On 2012-05-24 12:21:01 +, Alex Rønne Petersen 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
On 24-05-2012 16:03, Russel Winder wrote:
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 n
On 24-05-2012 15:38, Steven Schveighoffer wrote:
On Thu, 24 May 2012 08:54:45 -0400, Peter Alexander
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
On 24-05-2012 16:00, Michel Fortin wrote:
On 2012-05-24 13:38:01 +, "Steven Schveighoffer"
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),
On 24-05-2012 15:49, Steven Schveighoffer wrote:
On Thu, 24 May 2012 09:47:23 -0400, deadalnix 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
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 r
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.run
On 2012-05-24 13:38:01 +, "Steven Schveighoffer"
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
On Thu, 24 May 2012 09:47:23 -0400, deadalnix 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
unrefere
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 allowe
On Thu, 24 May 2012 08:54:45 -0400, Peter Alexander
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 r
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
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
unrefe
On 2012-05-24 12:21:01 +, Alex Rønne Petersen 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
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 arbitrari
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
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 i
64 matches
Mail list logo
