Re: Is MSDN wrong? or I made a mistake? about static member function
"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message
news:1152672877.772938.36990@m79g2000cwm.googlegroups.com...
C# further compounds the confusion by having some rule for allocating
some objects on the stack, and some on the heap, and it is not
apparent where your object is.
Yes it is very apparent as you know the type (value or not) of object.
Hmm, but I thought C# allocates classes on the heap and structs on the
stack? IOW, objects are on the heap and simple data types are on the stack?
Maybe I'm wrong, but this forces you to remember what is a class and what is
a struct. Seems like forcing you to remember something is error prone and
not really a benefit. (But then, doing away with Hungarian notation also
forces you to remember the type of each construct, which is error prone and
not really a benefit.)
It is necessary to know for deterministic finalization,
something else C# is weak in.
Its not really weak in it. It does provide a way to do it except that
it is not
readily apparent as most of the time you will not need it. However
these issues are not C# specific, rather .Net issues. Language really
has nothing to do with it.
Again, maybe I'm wrong, but I believe Managed C++ in 2005 has deterministic
destructors that always do the right thing, whereas the C# relies on
implementing IDisposable or something like that which still is not
guaranteed to be always called in a deterministic fashion.
Deterministic finalization is important cleaning up resources (such as
closing disk files, resetting cursors like CWaitCursor does, etc.), which is
as much a concern of .NET as in Unmanaged.
But I was wrong when I said deterministic finalization was affected by
whether the object was on the heap or on the stack. Re-thinking, this isn't
really true, since the finalization should occur when the object goes out of
scope; whether on the heap or stack doesn't matter. What DOES matter is if
an object needs to allocate a number of items which together total a large
amount of memory. If the object is on the heap, it can do so in place (e.g.
simply declare an array of 64K chars), instead of allocating on the heap,
which saves heap fragmentation. If the object is on the stack, the
allocation should be done on the heap to conserve stack space. I'm assuming
..NET shares the same concerns as in Managed: limited stack space and heap
fragmentation.
I couldn't care less what the history of the language is, but I find like
the two distinct notations: -> and .
This has no meaning in a pure .Net world. It seems you are comparing
C++ and managed world, which really is comparing apples and oranges.
Perhaps, I have very limited practice with C#, so maybe some of these issues
really are not relevant. But Joe was talking about the history of the
UNMANAGED languages, and for those, I defintely prefer distinct -> and .
(and also ::).
-- David