This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc-in-cxx: Garbage Collecting STL Containers


On Wed, Jun 25, 2008 at 9:04 AM, Basile STARYNKEVITCH
<basile@starynkevitch.net> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]