Re: [Boost-users] Boost Graph Library and Boehm Garbage Collector

(moving this to boost developer list) FBSL schrieb:
Hello
I am having trouble to garbage-collect adjacency_list<>. I have instanciated it with correctly garbage-collected vectors and lists (I have copied vecS and listS definitions, and added Boehm GC's default allocator so that they are garbage-collected). In my application I need to dynamically allocate many graphs, but it does not work, there is a (big) memory leak. Unfortunately, there is no template argument in adjacency_list<> to specify Boehm GC's allocator.
you're right, the BGL uses the default new operator to allocate memory which then isn't collected of course. so this makes it effectively impossible to use BGL with boehm GC. is there a boost guideline to allocate memory only through allocators which is violated here? (the "new" which is causing the leak(or one of your leaks?) in your code is at line 278 of graph/detail/adjacency_list.hpp in version 1.32) -- Stefan Strasser

On Apr 23, 2005, at 3:51 PM, Stefan Strasser wrote:
(moving this to boost developer list)
FBSL schrieb:
Hello I am having trouble to garbage-collect adjacency_list<>. I have instanciated it with correctly garbage-collected vectors and lists (I have copied vecS and listS definitions, and added Boehm GC's default allocator so that they are garbage-collected). In my application I need to dynamically allocate many graphs, but it does not work, there is a (big) memory leak. Unfortunately, there is no template argument in adjacency_list<> to specify Boehm GC's allocator.
you're right, the BGL uses the default new operator to allocate memory which then isn't collected of course. so this makes it effectively impossible to use BGL with boehm GC. is there a boost guideline to allocate memory only through allocators which is violated here?
There is no Boost-wide guideline that requires the use of allocators, but adjacency_list and adjacency_matrix should support allocators. I've logged this as a bug in the SourceForge bug tracker, but I don't know when we'll get around to fixing it. We could definitely use some help! Doug
participants (2)
-
Doug Gregor
-
Stefan Strasser