Hi, I'm sending this to you as the authors of the Boost Graph library. We have some applications of Boost.Graph where it would be desirable for us to be able to supply our own memory allocator that Boost.Graph would use when it needs to allocate memory for vertices, edges, or whatever. For example, we might want to allocate the graph in an arena and when we are done just deallocate the whole arena. Has there been any request from others for this? I would not think it would be too hard to add (e.g. for adjacency_list, add another template parameter for the allocator and use it whenever allocation is needed). I would be interested in hearing your feedback on this proposal. Thanks for your help. Richard L. Ford, Ph. D. Principal Member of Technical Staff Software Strategy and Solutions T 978-795-8584 F 978-795-2525
Hi Rich, There is some support for specifying your own allocator in adjacency_list by creating your own container tags and specializing the container_gen traits class. http://www.boost.org/libs/graph/doc/using_adjacency_list.html However, there are a few places in the code for adjacency_list where allocation is still being performed by plain old "new". I'd certainly be in favor of a clean up of the code to provide a way to completely control allocation. Cheers, Jeremy On Apr 2, 2007, at 12:56 PM, Ford, Rich wrote:
Hi,
I’m sending this to you as the authors of the Boost Graph library.
We have some applications of Boost.Graph where it would be desirable for us to be able to supply our own memory allocator that Boost.Graph would use when it needs to allocate memory for vertices, edges, or whatever. For example, we might want to allocate the graph in an arena and when we are done just deallocate the whole arena. Has there been any request from others for this? I would not think it would be too hard to add (e.g. for adjacency_list, add another template parameter for the allocator and use it whenever allocation is needed).
I would be interested in hearing your feedback on this proposal.
Thanks for your help.
<image001.jpg>
Richard L. Ford, Ph. D. Principal Member of Technical Staff Software Strategy and Solutions T 978-795-8584 F 978-795-2525
______________________________________ Jeremy Siek <jeremy.siek@colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder
Thanks for your response. Is this something you or the others on the BGL team are likely to do, or would you be open to patches from someone else who did this work? I'm not sure that we have the expertise or time to do this ourselves, although the advantages of being able to use BGL could out-weigh the cost of making it use custom allocators. I noticed there are some other additions coming such as the Lengauer/Tarjan dominator algorithm. I'm working in the area of compilers and would be interested in seeing other compiler-oriented algorithms added such as those needed in computing SSA. Thanks for all your hard work in providing BGL. It really is quite elegant. Rich -----Original Message----- From: Jeremy Siek [mailto:jeremy.siek@gmail.com] Sent: Monday, April 02, 2007 3:21 PM To: Ford, Rich Cc: lums@osl.iu.edu; llee@cs.indiana.edu; boost@lists.boost.org Subject: Re: [boost][Graph] User supplied allocators with Boost.Graph? Hi Rich, There is some support for specifying your own allocator in adjacency_list by creating your own container tags and specializing the container_gen traits class. http://www.boost.org/libs/graph/doc/using_adjacency_list.html However, there are a few places in the code for adjacency_list where allocation is still being performed by plain old "new". I'd certainly be in favor of a clean up of the code to provide a way to completely control allocation. Cheers, Jeremy On Apr 2, 2007, at 12:56 PM, Ford, Rich wrote:
Hi,
I'm sending this to you as the authors of the Boost Graph library.
We have some applications of Boost.Graph where it would be desirable for us to be able to supply our own memory allocator that Boost.Graph would use when it needs to allocate memory for vertices, edges, or whatever. For example, we might want to allocate the graph in an arena and when we are done just deallocate the whole arena. Has there been any request from others for this? I would not think it would be too hard to add (e.g. for adjacency_list, add another template parameter for the allocator and use it whenever allocation is needed).
I would be interested in hearing your feedback on this proposal.
Thanks for your help.
<image001.jpg>
Richard L. Ford, Ph. D. Principal Member of Technical Staff Software Strategy and Solutions T 978-795-8584 F 978-795-2525
______________________________________ Jeremy Siek <jeremy.siek@colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder
On Mon, 2007-04-02 at 16:42 -0400, Ford, Rich wrote:
Thanks for your response. Is this something you or the others on the BGL team are likely to do, or would you be open to patches from someone else who did this work? I'm not sure that we have the expertise or time to do this ourselves, although the advantages of being able to use BGL could out-weigh the cost of making it use custom allocators.
We would be happy to review patches to introduce this functionality into the BGL, and would integrate them into the library when they are ready. I can't speak for the other maintainers, but I won't have time to implement this extension myself for the foreseeable future.
I noticed there are some other additions coming such as the Lengauer/Tarjan dominator algorithm. I'm working in the area of compilers and would be interested in seeing other compiler-oriented algorithms added such as those needed in computing SSA.
So would I. As I recall, the author of the dominator implementation is also working in the area of static analysis, so we might see more work in this area. Cheers, Doug
participants (3)
-
Douglas Gregor -
Ford, Rich -
Jeremy Siek