On Wed, Jun 25, 2008 at 9:04 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Chris Jefferson wrote:
>>
>> Could someone point me towards what is necessary to add STL containers
>> to the garbage collector?
>>
>> One big problem with garbage collecting in C++ is the need to run
>> destructors. If the (I believe very reasonable) decision is made to
>> require that running destructors is not necessary for garbage
>> collected types, then my experience is doing gc is very easy, and for
>> garbage collection it's easy to just look at the internal members
>> which all behave "sensibly".
>>
>> Stripping away all the C++isms, and assuming that we use the default
>> allocator which uses malloc, then a std::vector is just a struct
>>
>> struct vector
>> {
>> T* begin;
>> T* finish;
>> T* end_of_storage;
>> };
>>
>> Where we increment finish whenever we add something to the vector,
>> until finish = end_of_storage, at which point new memory is allocated,
>> the data is copied across, and then the old memory is freed. I can't
>> think of any other (or any simpler) way to construct a variable sized
>> container, in either C or C++.
>>
>> Other containers are similar.
>
> I fully agree on that point. To summarize: most of the classes in the
> gcc-in-cxx should have no destructor at all, or a trivial destructor which
> only destroys the data inside.
I would expect GCC to provide its own allocators (GC, obstacks, etc.)
when using
STL containers. Consequently I believe the above is too strong a requirement.
I suspect what you really want is not to have destructors with semantics
interference with GC. For example, it would be OK to have
vector<BasicBlock, GC_Alloc> as long as BasicBlock itself has GC_Alloc'd members
or has semantically uninteresting destructor.
Also, I would expect C++ idiomatic constructs such as RAII for managing local
resources, or monitoring function calls, etc.
Or, forget STL containers and embrace NIH.
-- Gaby
