|
Re: A Brief Look at C++0x
|
Posted: Jan 13, 2006 4:41 AM
|
|
> retention, but this is a different problem.) However, > garbage collection is not without its costs -- among them > performance impact, pauses, configuration complexity, and > nondeterministic finalization."
I know all about gc problems - but with C++, these problems are minimal. Let's see them:
1) performance impact.
C++ has advantages over Java. Specifically, Java requires all objects to be on the heap, and Java code is supervised. On the other hand, most C++ objects, especially small ones, are allocated on the stack, and code runs native. So C++ gc will not slow down a program, since the number of actual objects on the heap are much less than in Java, and C++ code does not need to be monitored. I see no performance impact.
2) pauses.
GC will be optional. If you are doing a real-time project and pauses are unacceptable, don't use it.
3) configuration complexity.
I don't understand what that is. What complexities?
4) nondeterministic finalization.
Order of finalization is not something GC must be concerned with. Destructors/finalizers are there in order to finalize resources that are is difficult to determine when they shall be finalized. In most cases though, finalization of resources takes place when some sort of event takes place: a user option, a program exit, an algorithm end, a new file opened, etc. Furthermore, C++ has RAII, which Java lacks.
> at I describe. And keep in mind that C++ pointers can be > passed to the another subsystems which not under control > of garbage collector. This is not closed Java world. For > example in Windows GUI programming I can store one > available reference to object in special lParam data field > what maintained internally by common controls such as > TreeView, ListView and so on. How garbage collector will > known that this object live if no other references to it > exists? This object must by deleted only in response to > the special Windows message, not by any collectors.
It is silly to store garbage-collected pointers in non-pointer structures. The solution is one: don't do it.
For those libraries that manage code manually, the solution is to keep doing it manually, unless a new version of the library comes that is garbage collected.
> > > > I'm afraid that if garbage collection will become the > > > he part of standard runtime support then any novice > or > > > semi-skilled programmer will never think about the > > memory > > > managament rely on the garbage collector > possibilities. > > > > GC shall be optional. > > Please clarify for me what does mean "optional".
Optional means that the programmer can
a) allocate a data structure either in the garbage-collected heap or in the manually managed heap
b) turn GC off and on at will
> > For example some library LibA rely on GC. > Another library LibB uses LibA internaly in few places. > LibB use handmade memory managament.
Since LibB uses LibA, it means LibB is constructed after LibA is constructed. Therefore I see no reason why LibB would have manual memory management where it knows that LibA uses GC.
> Some questions: > - Will be GC runtime engine linked to my program?
Yes.
> - Will be GC engine recieve control in any point of my > program even if I use LibB only on startup?
I do not understand this question fully, but if you use GC stuff, then the GC engine will be invoked somewhere.
> - My program is single threaded. How GC recieve control?
Personally I see no reason why GC should be a separate thread. So my reply is 'a single threaded app with gc shall have no other threads'.
|
|