• Denis Shelomovskij (21/21) May 04 2012 This idea is too obvious and I suppose I'm the only one not knowing it,
• Jonathan M Davis (7/31) May 04 2012 And why would you even _have_ a dead object? It's the GC's job to destro...
• Simen Kjaeraas (6/39) May 04 2012 I believe the idea was that it'd blow up if you use it unwisely. clear
• Steven Schveighoffer (4/9) May 04 2012 clear zeros out the vtable, so it's highly unlikely it "just works".
• Simen Kjaeraas (3/11) May 05 2012 Final functions still work, as they don't need the vtable.
• Steven Schveighoffer (6/19) May 07 2012 Just thought of this:
• Sean Kelly (6/12) May 04 2012 construction and up to finalization.

Denis Shelomovskij <verylonglogin.reg gmail.com> writes:

This idea is too obvious and I suppose I'm the only one not knowing it, 
but I have never seen it's implementation. Why?

The idea:
1. `Object` class has hidden `isAlive` field which is true since 
construction and up to finalization.
2. Every method asserts that the object is alive first.
3. There is an `finalize` function that just rt_finalize an object in 
debug mode but can even free memory in release mode.

Isn't it no-brainer? Isn't it the only way to debug manual memory 
management and shared resources without error-prone boilerplate?


manually check the object isn't disposed every time I use it or in every 
it's method to find where I'm doing something with a disposed object by 
a mistake.


IMHO finding using of dead references is almost as major as not allowing 
to free memory of alive objects (I mean GC), but GC is often implemented 
and dead references detection isn't.

Strongly require your thoughts.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, May 04, 2012 18:28:51 Denis Shelomovskij wrote:
 This idea is too obvious and I suppose I'm the only one not knowing it,
 but I have never seen it's implementation. Why?
 
 The idea:
 1. `Object` class has hidden `isAlive` field which is true since
 construction and up to finalization.
 2. Every method asserts that the object is alive first.
 3. There is an `finalize` function that just rt_finalize an object in
 debug mode but can even free memory in release mode.
 
 Isn't it no-brainer? Isn't it the only way to debug manual memory
 management and shared resources without error-prone boilerplate?
 

 manually check the object isn't disposed every time I use it or in every
 it's method to find where I'm doing something with a disposed object by
 a mistake.
 
 
 IMHO finding using of dead references is almost as major as not allowing
 to free memory of alive objects (I mean GC), but GC is often implemented
 and dead references detection isn't.
 
 Strongly require your thoughts.

And why would you even _have_ a dead object? It's the GC's job to destroy and 
free GC-allocated objects. The only case where you might normally run into a 
dead object would be if you use clear, but if you're using clear in situations 
where you then might end up using the object afterwards, then it's likely 
you're using it unwisely.

- Jonathan M Davis

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Fri, 04 May 2012 19:29:11 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Friday, May 04, 2012 18:28:51 Denis Shelomovskij wrote:
 This idea is too obvious and I suppose I'm the only one not knowing it,
 but I have never seen it's implementation. Why?

 The idea:
 1. `Object` class has hidden `isAlive` field which is true since
 construction and up to finalization.
 2. Every method asserts that the object is alive first.
 3. There is an `finalize` function that just rt_finalize an object in
 debug mode but can even free memory in release mode.

 Isn't it no-brainer? Isn't it the only way to debug manual memory
 management and shared resources without error-prone boilerplate?


 manually check the object isn't disposed every time I use it or in every
 it's method to find where I'm doing something with a disposed object by
 a mistake.


 IMHO finding using of dead references is almost as major as not allowing
 to free memory of alive objects (I mean GC), but GC is often implemented
 and dead references detection isn't.

 Strongly require your thoughts.

 And why would you even _have_ a dead object? It's the GC's job to  
 destroy and
 free GC-allocated objects. The only case where you might normally run  
 into a
 dead object would be if you use clear, but if you're using clear in  
 situations
 where you then might end up using the object afterwards, then it's likely
 you're using it unwisely.

I believe the idea was that it'd blow up if you use it unwisely. clear  
might
do that, but if you're unlucky, it'll 'work' just fine, giving you problems
later.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 04 May 2012 14:50:06 -0400, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 I believe the idea was that it'd blow up if you use it unwisely. clear  
 might
 do that, but if you're unlucky, it'll 'work' just fine, giving you  
 problems
 later.

clear zeros out the vtable, so it's highly unlikely it "just works".

-Steve

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Fri, 04 May 2012 21:07:20 +0200, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Fri, 04 May 2012 14:50:06 -0400, Simen Kjaeraas  
 <simen.kjaras gmail.com> wrote:

 I believe the idea was that it'd blow up if you use it unwisely. clear  
 might
 do that, but if you're unlucky, it'll 'work' just fine, giving you  
 problems
 later.

 clear zeros out the vtable, so it's highly unlikely it "just works".

Final functions still work, as they don't need the vtable.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 05 May 2012 17:12:14 -0400, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Fri, 04 May 2012 21:07:20 +0200, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 On Fri, 04 May 2012 14:50:06 -0400, Simen Kjaeraas  
 <simen.kjaras gmail.com> wrote:

 I believe the idea was that it'd blow up if you use it unwisely. clear  
 might
 do that, but if you're unlucky, it'll 'work' just fine, giving you  
 problems
 later.

 clear zeros out the vtable, so it's highly unlikely it "just works".

 Final functions still work, as they don't need the vtable.

Just thought of this:

Object.invariant uses the vtable I believe, so unless you only ever test  
in release mode, you will crash on every method call.

-Steve

Sean Kelly <sean invisibleduck.org> writes:

On May 4, 2012, at 7:28 AM, Denis Shelomovskij wrote:

 This idea is too obvious and I suppose I'm the only one not knowing =

it, but I have never seen it's implementation. Why?
=20
 The idea:
 1. `Object` class has hidden `isAlive` field which is true since =

construction and up to finalization.
 2. Every method asserts that the object is alive first.
 3. There is an `finalize` function that just rt_finalize an object in =

debug mode but can even free memory in release mode.

rt_finalize currently nulls out the vtbl pointer, which can server as an =
isAlive flag if desired.=