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?

This is what I missed in C#, where I can dispose an object but I have to 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

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?
> 
> This is what I missed in C#, where I can dispose an object but I have to 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

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?
>>
>> This is what I missed in C#, where I can dispose an object but I have to
>> 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.

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?
> 
> 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.

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

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.

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