Boost logo

Boost :

From: Ford, Rich (Rich.Ford_at_[hidden])
Date: 2007-04-02 16:42:08

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


-----Original Message-----
From: Jeremy Siek [mailto:jeremy.siek_at_[hidden]]
Sent: Monday, April 02, 2007 3:21 PM
To: Ford, Rich
Cc: lums_at_[hidden]; llee_at_[hidden]; boost_at_[hidden]
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.

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


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_at_[hidden]>
Visiting Assistant Professor
Department of Computer Science
University of Colorado at Boulder

Boost list run by bdawes at, gregod at, cpdaniel at, john at