Thank's
Per Thygesen
--
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...
Why do you say it's a mistake?
Jason
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
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
"Artur Biesiadowski" <ab...@pg.gda.pl> wrote in message
news:3A636A9A...@pg.gda.pl...
--
Jonathan Allen
"Griffo" <dearpo...@hotmail.com> wrote in message
news:#mOKprzfAHA.1232@tkmsftngp03...
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...
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
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...
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...
What is it?
Jason
using { }. Check the C# language specification online:
http://msdn.microsoft.com/net/ecma/
On page 182.
"Alexander Jung" <ju...@new-line.de> wrote in message
news:Ozvn3Z4fAHA.1940@tkmsftngp04...
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
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...
The only thing I ever liked about Java...
*happily tossing malloc() and ref counting over his shoulder*
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...