Deterministic destruction

20 views
Skip to first unread message

Per Thygesen

unread,
Jan 15, 2001, 5:04:13 AM1/15/01
to
It seem to me that C# repeat the Java mistake
with non-deterministic destruction. Is that correct ?

Thank's
Per Thygesen

Michael (michka) Kaplan

unread,
Jan 15, 2001, 7:06:02 AM1/15/01
to
Yes, it is.

--
MichKa

a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Per Thygesen" <perth...@hotmail.com> wrote in message
news:#RK84ntfAHA.1544@tkmsftngp02...

Jason Bock

unread,
Jan 15, 2001, 10:44:45 AM1/15/01
to
"Per Thygesen" <perth...@hotmail.com> wrote in message
news:#RK84ntfAHA.1544@tkmsftngp02...
> It seem to me that C# repeat the Java mistake
> with non-deterministic destruction. Is that correct ?

Why do you say it's a mistake?

Jason


Roberto Martinez-Brunet

unread,
Jan 15, 2001, 1:58:11 PM1/15/01
to
From

http://msdn.microsoft.com/library/default.asp?URL=/library/welcome/dsmsdn/dr
guinet121500.htm

<quote>

Destructors are used by some object-oriented systems, especially C++, to
clean up objects just before they're destroyed. The .NET Framework does not
support C++ style destructors-specifically, it does not support
deterministic destruction, where you know exactly when each object's
destructor is called. (However, C# will be supporting a scheme to provide an
automatic deterministic call to a Dispose method in Beta 2-more on this when
Beta 2 ships.)

</quote>

Hope it helps

Roberto

Artur Biesiadowski

unread,
Jan 15, 2001, 4:24:42 PM1/15/01
to

Per Thygesen wrote:
>
> It seem to me that C# repeat the Java mistake
> with non-deterministic destruction. Is that correct ?

Yes. On the other hand they have not chosen to repeat C++ mistake of
leaking memory :)

Artur

Griffo

unread,
Jan 15, 2001, 4:35:22 PM1/15/01
to
My question is why don't they just give us destructors, it's not that they
have to actually free the memory, just notify us. True, reference counting
would have to be tracked as in COM but still, they ought to at least be able
to tell us an object is losing scope, and once they have that ability, they
code (assuming reference counting is there) let us know when the final
release happens, meanwhile, garbage collection remains the same, memory is
not freed, it's just a matter of notification.


"Artur Biesiadowski" <ab...@pg.gda.pl> wrote in message
news:3A636A9A...@pg.gda.pl...

Jonathan Allen

unread,
Jan 15, 2001, 5:37:00 PM1/15/01
to
Reference counting is slow and leads to circular references (memory leaks).
Without reference counting, you have no way to know an object has been
released.

--
Jonathan Allen


"Griffo" <dearpo...@hotmail.com> wrote in message
news:#mOKprzfAHA.1232@tkmsftngp03...

Alexander Jung

unread,
Jan 16, 2001, 1:37:55 AM1/16/01
to
Hi,

For heap allocated objects a mechanism to explicitely freeing them could
solve the problem. But this leads either to dangling references (if done
without check) or to the same amount of work as a complete garbage
collection requires. On the other hand, you can't be shure wether a
particular object is actually freed if things like finalization and
generations kick in ....

But providing a deterministic destructor for structs (possible without
reference counting or garbage collection since they're stack allocated value
types) should be possible. With such a mechanism I could solve most
destructor-related problems.

Alexander

"Jonathan Allen" <greyw...@bigfoot.com> schrieb im Newsbeitrag
news:OsweCu1fAHA.1588@tkmsftngp05...

Per Thygesen

unread,
Jan 16, 2001, 3:44:10 AM1/16/01
to
Maybe 'mistake' is a strong word, but I need every argument I can get,
for using for C# (and not Java...).

I know that deterministic destruction comes at a cost, and I am not
suggesting that the Garbage Collector should be removed. Let the
GC handle memory resources, and give the programmer some other
way for deterministic destruction.

Per


Jonathan Allen

unread,
Jan 16, 2001, 2:52:36 AM1/16/01
to
> But providing a deterministic destructor for structs should be possible.

That only works for value types stored in the stack. They can also be boxed
and placed on the heap. You have to cover all situations the programmer
might use it in or it doesn't work.

Note: For any object (value or reference) that has the lifetime of the
function it's declared in, there is special syntax in Beta 2 that guarantees
disposal.

--
Jonathan Allen


"Alexander Jung" <ju...@new-line.de> wrote in message
news:Ozvn3Z4fAHA.1940@tkmsftngp04...

Jonathan Allen

unread,
Jan 16, 2001, 3:33:43 AM1/16/01
to
> and give the programmer some other
> way for deterministic destruction.

You do by way of Dispose. It's automatic deterministic destruction that
isn't supported.

BTW, automatic deterministic destruction seems to me to be at odds with the
C++/C# mentality. It is the sort of auto-magical effect the C users frown
upon and use as a reason not to use VB. I am surprised that manually calling
Dispose doesn't seem more natural to them.

--
Jonathan Allen


"Per Thygesen" <perth...@hotmail.com> wrote in message

news:#lKyzf5fAHA.1448@tkmsftngp03...

Jason Bock

unread,
Jan 16, 2001, 11:55:59 AM1/16/01
to
"Jonathan Allen" <greyw...@bigfoot.com> wrote in message
news:#0SFDk5fAHA.1600@tkmsftngp02...

> Note: For any object (value or reference) that has the lifetime of the
> function it's declared in, there is special syntax in Beta 2 that
guarantees
> disposal.

What is it?

Jason


Sjoerd Verweij

unread,
Jan 16, 2001, 12:05:38 PM1/16/01
to
> What is it?

using { }. Check the C# language specification online:
http://msdn.microsoft.com/net/ecma/

On page 182.

Eric Gunnerson (MSFT)

unread,
Jan 16, 2001, 12:46:59 PM1/16/01
to
Also note that deterministic structs would make exception handling much more
expensive in the non-exception case.

"Alexander Jung" <ju...@new-line.de> wrote in message
news:Ozvn3Z4fAHA.1940@tkmsftngp04...

Per Thygesen

unread,
Jan 16, 2001, 9:44:23 PM1/16/01
to
> Note: For any object (value or reference) that has the lifetime of the
> function it's declared in, there is special syntax in Beta 2 that
guarantees
> disposal.

But the client still have to behave properly with this syntax ?

Here on day 5 of my new c# life, I think I have found (google search) a
solution
to my problem: http://www.develop.com/dbox/dotnet/unwind/

Per


Alexander Jung

unread,
Jan 17, 2001, 2:54:01 AM1/17/01
to
Hi,

right, but this should only be the case when deterministic destruction for
structs (let's call them destructors or d'tors- just because it's easier to
write :-) ) is actually used.

The situation right now is as follows:
1. gc and finalize does the work automaticly that I had to do manually
before (and could easily forget). Less work to do and fewer errors. Great.
2. This simplifies the runtime environment and makes it more stable and in
many cases even mor performant. Great, too.
3. Resources that are gc'ed may stay in memory for a longer time (AFAIK they
might not be finalized at all under rare circumstances, e.g. at program
termination).

In most cases 1 and 2 outrule 3 (after all, who cares wether a string is
actually freed or not?) and the time lag introduced by 3 may be compensated
by 2.

But there are the rare but problematic expensive resources (in terms of
memory consumption or holding locks), such as db-connections, open files
etc. . If you know what you're doing (as we all do :-)) you simply have more
boilerplate code to write. On the other hand the most important quality of a
good developer is lazyness and in most projects I did with customers (the
customers developers) I meet developers that didn't always know, what they
were doing (sometimes this was the rule not the exception). For those cases,
any mechanism for d'tors would be very wellcome.

AFAIK you've been a member of the QS-Team, so this argument should please
you :-))


"Eric Gunnerson (MSFT)" <eri...@no.spam.microsoft.com> schrieb im
Newsbeitrag news:uhvmUR#fAHA.1756@tkmsftngp05...

Sjoerd Verweij

unread,
Jan 17, 2001, 11:58:37 AM1/17/01
to

From the time I've spent with .NET so far, my suspicions have been
proven right on the money: yes, you will screw up, forgetting to
dispose left and right. Yes, that is a bug. And yes, those bugs are
wonderfully easy to find.

The only thing I ever liked about Java...

*happily tossing malloc() and ref counting over his shoulder*

Jonathan Allen

unread,
Jan 17, 2001, 4:57:12 PM1/17/01
to
> Yes, that is a bug. And yes, those bugs are
> wonderfully easy to find.

And if you don't find them, the GC will eventually get around to them.

--
Jonathan Allen


"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a65cec9....@msnews.microsoft.com...

Reply all
Reply to author
Forward
0 new messages