Tony Johansson wrote:
Hello!
You mentioned that you don´t need to care about memory management in
Windows Forms Application(.NE T when you use C++, this can or can not
be an advantage.
Actually, you do still have to worry about memory management, you just worry
in a different way, about different details.
Do you really mean that you don't have to use the delete to delete
dynamically created object any more?
Yes.
This mean that there must exist some kind of garbage collector(gc)
taking care of this. Is that right?
Yes.
As there must exist some kínd of gc this must affect the execution
speed as you also say.
Yes. The performance under a GC system is different than a non-GC. The
theorists tell us that the amortized time per allocation with a GC is
substantially less than with a traditional allocator, yet many people will
complain about the performance of GC apps being sluggish.
The main difference is this: Allocation from the collecting memory manager
is lightning fast (can be as fast as a single instruction to allocate a
block of memory). The reclamation speed is orders of matgnitude slower, but
doesn't occur very often (many programs will run to completion without ever
invoking a collect operation). How those facts affect performance depends a
lot on how your application uses memory (and if you ever force a GC
collect - forcing a collect almost never improves performance).
Under a GC system instead of worrying about deleting dynamically allocated
memory, you worry about a couple of other things:
1. GC "Generation s". The .NET GC is a "generation al collector". When
objects are allocated, they are in Gen 0. When the GC runs, all active
objects in Gen 0 are "promoted" to Gen 1, etc, up to Gen 2 (or 3 generations
total). The cost of collecting Gen1 is potentially orders of magnitude
higher than collecting Gen 0, likewise for Gen 2. So under such a
collector, you worry about causing objects to unnecessarily survive into Gen
1 or Gen 2, and there are specific programming patterns that can be used to
help limit promotion of objects out of Gen 0.
2. Object lifetime. Under C++, an object's lifetime and the lifetime of the
memory it occupies are always the same. Under .NET, this isn't so. Because
objects may never be collected (freed), there has to be another way to
signal the end of the useful lifetime of the object. Under .NET (and Java),
this is done through the IDispose pattern. C++/CLI automates the
IDisposasble pattern so that you can apply the delete operator to a "heap
object" to end it's useful lifetime (but this has nothing to do with the
lifetime of the memory if occupies). C++/CLI also allows you to declare
"stack based" objects that are really proxies for heap-based objects.
Standard C++ destructor semantics are applied to these objects so their
lifetime (but not their memory allocation) ends (by calling Dispose()) when
the block where the object is declared is exited. In fact, under C++/CLI,
the normal C++ destructor is mapped to IDisposable.Dis pose. C# provides a
special syntactical structure (a using block) to handle deterministic
destruction - calling Dispose(). It's neat, but you have to remember to do
it. Under C++/CLI, it happens automatically like you've come to expect for
C++ destructors.
You might find these links helpful in understanding C++/CLI and porting your
MFC application to VC 2005. Spend some time searching MSDN, and looking at
articles "near" these in the table of contents - there's lots of information
out there from Microsoft on this topic, you just have to look for it.
http://msdn.microsoft.com/msdnmag/issues/05/02/PureC/ http://msdn.microsoft.com/library/de...BakerDozen.asp http://msdn.microsoft.com/library/en...asp?frame=true http://msdn.microsoft.com/library/en...asp?frame=true
-cd
