> I have an application written in C++, and now I'm going to add another
module to it, which I'm going to write in C#, and wrap it as a COM.
The new module is going to interact with the existing application during
runtime (call the application's methods and run some BL according to the
return values). My concern is regarding the GC mechanism of the .NET
environment - I know that there is an effect on the runtime, because of
delay that occurred while the environment calls the GC, but my question
is - can it be that during this "pause", the C++ application, which executes
some other COM's, will miss their return values because the GC was called? or
that while calling the GC, ALL the events/calls are being "paused" and
"wake up" after the delay?
The effect is very small so I doubt that you will even notice it.
In games you might see this effect that your frame rate drops for a few
heartbeats which could be a small problem.
The biggest slowdown might occur is you call a .NET function that was not
used yet and use other dll's and thus must be compiled by the CLR.
..NET functions work exactly the same way as normal DLL functions, it is very
unlikely that a return value gets missed, unless you do something very funny
in your code in combination with multi-threading.
One important thing to know about the GC is that it only disposes memory
that it discovers that it has no pointer assigned to it. It does this by
analyzing your memory, And it never gave any problems in my code in the last
few years I have been using it. There is no hidden generated code in your
application of you disassemble it, that calls a destructor or anything else
that you would find in C++ code. So this actually speeds up you code,
because it only disposes it when it runs out of memory.
Care must be taken about limited resources, like file handles, and paint
brushes and others... These are the only things that you must actually
dispose yourself, but don't do it in the destructor since that is called
when you run out of memory, which is anoying if a file does not gets closed
for seconds because the GC has not started up to call de destructor.
