David Abrahams wrote:
on Mon Apr 13 2009, Achilleas Margaritis <axilmar-AT-gmail.com> wrote:
I would appreciate it if people could take a look and share their opinions on it.
I haven't looked at it, but IMO the biggest obstacle to effective GC for C++ isn't the lack of a library (Boehm's collector is pretty good AFAIK).
I have to disagree with that. According to Boehm himself (http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html): "The C++ interface is implemented as a thin layer on the C interface. Unfortunately, this thin layer appears to be very sensitive to variations in C++ implementations, particularly since it tries to replace the global ::new operator, something that appears to not be well-standardized. Your platform may need minor adjustments in this layer (gc_cpp.cc, gc_cpp.h, and possibly gc_allocator.h). Such changes do not require understanding of collector internals, though they may require a good understanding of your platform. (Patches enhancing portability are welcome. But it's easy to break one platform by fixing another.) " I have tried to use the Boehm GC in C++ and there were many problems: 1) can not be integrated with threading libraries such as Qt threads or boost threads. For example, under Windows, Boehm GC supposes you use Win32 threads, and it provides functions that replace Win32 calls. 2) the replacement of the global operator new creates many problems with 3rd party libraries which provide their own operator global new (MFC, for example). 3) there are few details on what is supposed to work with dlls and globals initialized before main(). I tried asking on the newsgroup, they did not know the answer. They said that it's platform specific, and sometimes allocating objects before main is ok, sometimes it is not, sometimes you have to call gc_init(), sometimes you have not to etc. I can point you to the relevant discussions on the boehm gc newsgroup, if you wish.
It's the lack of a programming model that integrates destructors and peoples' legitimate expectations that they will be called to release non-memory resxources. What can you say about the non-memory resources owned by a GC'd object that contains, say, a mutex?
Personally, I don't see why resources like mutexes or files should be managed like memory. Resources like that are "binary" resources: they have two states (locked/unlocked, opened/closed), which is perfectly suited for RAII. Can you please elaborate on the problem of destructors? I have read some papers that say that gc and destructors don't play well together, but I did not really agree with that. An example would be appreciated.