[Gc] C++ API enhancement proposal

Christophe Meessen meessen at cppm.in2p3.fr
Fri May 11 01:42:01 PDT 2007


skaller a écrit :
> On Fri, 2007-05-11 at 08:48 +0200, Christophe Meessen wrote:
>   
>> add in gc_cpp.cpp
>>
>>    struct GC_initializer { GC_init_struct() { GC_INIT(); } }
>>    GC_initializer gc_initializer;
>>
>> Note: it won't completely eliminate the problem of global instance
>> initialization alloacting blocks because we can't ensure libgc is
>> initialized first. 
>>     
>
> Yes, and it's a bad idea for that reason. It's important
> to delegate the responsibility to the programmer BECAUSE
> there is no safe automatic solution.
>   
It is not safe, but it is safer than the current working model and a 
programmer won't be able to do better then that. So delegating won't help.

>> Better than nothing, in wait of gc support in C++.
>>     
>
> C++ will never have gc support: C++ isn't compatible
> with garbage collection.
>   
With supporting gc, compilers can ensure the gc is initialized before 
starting to instantitate global variables. They can also ensure 
optimizations won't break garbage collection. It should of course be 
optional because many C++ programs don't need any gc. But there exists 
use cases where a gc is required. This is what I am facing and the 
reason why I'm trying to get it running properly for my application. I 
would save the dependency to this third party library if it was possible.

> Just don't wait for C++ to get 'garbage collection': C++ is
> a crap language already, it can't be fixed by adding a collector.
> Far too much C++ is dependent on RAII which isn't compatible for
> current collector technology.
I don't agree on this. This is just a matter of code design and as long 
as user is in control of what class and data is collectable and /or 
inspected  the user can pick the best of both worlds. This would make 
c++ with gc support more versatile to other existing languages with gc 
support built in. It will add some complexity to C++ programming because 
users will have to determine if they need gc or not and where. But this 
is also true for many other features of C++.

Whether it is a good or bad language depends on many other things than 
the syntax it self. It depends on the type of application and execution 
space/time constrains, it depends on the programmer competence, it 
depends on development time constrains, on the targeted user base, etc.  
Assembly can be better than anything else in some very particular context.

Let user choose the language they'll use and let c++ programer choose 
where and when to use gc in their code. I think it should be kept 
explicit as in current libgc C++ API by using specific base classes or 
new operator placement options.




More information about the Gc mailing list