You can mark an object for collection and call GC.Collect();
Besides whats the big deal about it possibly not being collected as soon as all references to a heap object are gone? If the program needed more memory for an allocation it would immediately collect everything that is safe to be collected. You probably can't manage it better yourself.
well, for 1, just because you mark an object for collection doesn't mean it will be collected, even with GC.Collect. objects get elevated to different generations depending on how long they live. GC.Collect is an all or nothing kinda deal, so if you want to free up memory for object a, which is generation 1, you need to free up *all* objects in generation 1, not to mention you have no idea what order objects are collected.Originally Posted by valaris
also, true deterministic allocation/deallocation is important for applications where predictability is a requirement. many high-performance applications fall into this category.
I hear this a lot, and it simply isn't true.You probably can't manage it better yourself. (Memory management )
If it were even close to true, the wide range of C++ applications that manage rather large volumes of information (like SQL engines, 3D Studio Max, AutoCAD, FormZ, Pro-E, Catia, Photoshop) wouldn't work as well as they do.
In fact, it is precisely because you CAN manage it better yourself that these ambitious applications aren't written in Java, C# or similar languages.
I'll give you this, however - you can't manage it better with the same simplicity - that much is true.
Also, the subject relative to deterministic destruction isn't as much about memory management specifically as it is about the RAII paradigm (or design pattern, if you think of it that way).
