On 09/23/07 13:31, Achilleas Margaritis wrote:
O/H Larry Evans έγραψε: [snip]
The main_stl.zip in boost-vault/memory uses Sebastian's suggestion and it seems to work. It runs a little std_list test, then a GCBench with std:pair, then GCBench with std_list<., gc_allocator>.
As (I think) you're pointing out above, the std_list<T,gc_allocator<T> > would define gc_allocator<T>::pointer as gc_ptr<T>, which is never used in std_list at all because the std_list stores the complete T (not T*) in std_list<...>::node. I can see where this would be confusing and is a shortcoming of the allocator model. It just happens to work in this case.
I am not really following you. Does your STL list class use the class gc_allocator<T> or not? and if it does, does it use it fully for all its operations or for some of them?
It can, just like std::list can. IOW, it can be the 2nd template parameter. The list_pair template (derived from std_list) uses gc_allocator as the 2nd template parameter of its superclass, std_list<Node,gc_allocator<Node> >. It doesn't use it for any operations because it's part of the nested std::list<.,.>::node used to implement the list. Only push_back was coded since that's the only one used. I guess the std_list::empty is not standard; however, that's not really important since the only purpose was to demonstrate how, possibly a future std::list, could be coded to allow your gc_allocator to be used. Now that I think about it, maybe only the std_list::node::_next needs to be a gc_ptr<.>. That would save some time.