Re: [boost] portable precise garbage collector for C++

From: Achilleas Margaritis (axilmar_at_[hidden])
Date: 2007-09-21 12:26:51

O/H Larry Evans έγραψε:
> On 09/21/07 04:14, Achilleas Margaritis wrote:
>> O/H Kim Barrett έγραψε:
>>> At 2:06 AM +0300 9/21/07, Achilleas Margaritis wrote:
>>>> I thought std containers use the allocator::pointer type for their pointers.
>>> Unfortunately, not necessarily. They're permitted to bypass that and use
>>> T* directly. Ion Gaztañaga ran into this when trying to put containers
>>> into shared memory for boost.interprocess.
>>> _______________________________________________
>>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>>>
>> The collector offers the possibility of customizing the scanning 
>> procedure (the procedure which scans a block for pointers) through the 
>> class gc_traits<T>. So if there is a data structure where gc_ptr<T> can 
>> not be used, a custom scan routine especially coded for the data 
>> structure in question can solve the problem.
> 
> Given the following:
> 
>    std::list<gc_ptr<Node> > node_list;
> 
> where Node is defined in cppgc/src/main.cpp,
> then no gc_ptr's within node_list would be
> registered as root pointers; so, wouldn't
> any Nodes of the gc_ptr's pushed into node_list be
> collected?  I guess I don't understand how a customized
> scanner would help.  Sure, once it's known that
> node_list contains gc_ptr's, the scanner could be
> called, but the collector first needs to be notified
> of that fact.
> 
> Am I missing something.

You have to define the appropriate allocator (in this case, 
gc_allocator<Node>) for the std::list to get its member pointers 
registered with the collector. gc_allocator<T> defines its pointer as 
gc_ptr<T>:

std::list<gc_ptr<Node>, gc_allocator<gc_ptr<Node> > > node_list;

Although I made the allocator, it does not work with the VC8 STL or the 
mingw STL, for the reason mentioned above (STL implementors choosing T* 
over allocator::pointer).

Is there an STL implementation without this problem? perhaps STLPort? I 
have to try it myself, but if anyone knows, please tell me.