From: John Peterson <peterson@cf...> - 2005-06-06 18:39:21
I think we should really start taking advantage of the capabilities in
boost, especially the boost::shared_ptr mentioned in the subject line.
The main advantage to using boost::shared_ptr is that they may be
placed in STL containers while AutoPtr's may not. Deal.II has
apparently been distributing parts of boost for a while now, so I'm
going to take a look at what they've done. The shared_ptr is also very
useful for safely reducing header dependencies, since the template arg
can be an incomplete type.
From: Roy Stogner <roystgnr@ic...> - 2005-06-06 19:07:25
On Mon, 6 Jun 2005, John Peterson wrote:
> I think we should really start taking advantage of the capabilities in
> boost, especially the boost::shared_ptr mentioned in the subject line.
> The main advantage to using boost::shared_ptr is that they may be
> placed in STL containers while AutoPtr's may not.
The main advantage I've seen is that the idea of shared responsibility
for memory management can make APIs less error-prone. Between
auto_ptr, shared_ptr, and references, my pseudo-dial-an-operator code
for deal.II pretty much never used a naked pointer. We shouldn't do
that in libMesh's lower-level code (shared_ptrs aren't as fast as
naked ones), but it might be helpful in APIs exposed to the user.
Normally (in C/C++ in general, not libMesh in particular), any time a
function takes a pointer or reference argument, the user has to worry
about how long the object referred to will live. Does this function
save a pointer for later use? Do I have to make sure this object
doesn't go out of scope before it's used? Similarly, if a function
returns a pointer then the user has to worry about whether the
function allocated memory at the other end of that pointer that has to
be deleted to avoid being leaked.
With shared_ptrs, the memory management is explicitly stated in the
function declaration: there will be others sharing the use of this
object, but its existance is reference counted so as long as you keep
your references wrapped in shared_ptr you don't have to worry about
deleting them too early or too late.
The performance tradeoff will be something to worry about, and any
backwards incompatible API changes should wait until after 0.5.0 is
out and has been tested for a while, but I like the idea.
deal.II includes a boost_local subset of boost in its contrib
directory. Perhaps we should do the same for maximum compatibility,
but I'd want configure to test for user-installed boost libraries
first. Boost is more popular than other external packages we use like
PETSc, and easier to install too.
Get latest updates about Open Source Projects, Conferences and News.