Boost logo

Boost :

Subject: Re: [boost] Review of a safer memory management approach for C++?
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-05-26 20:27:54


Bartlett, Roscoe A wrote:
> Hello Boost developers,
>
> I am interested in finding one or more individuals who are
> knowledgeable about memory management in C++ (and especially of the
> reference-counting approach taken by boost::shared_ptr and
> boost::weak_ptr) to review an idea for a comprehensive approach to
> safer memory management in C++ that encapsulates all raw C++ pointers
> in high-level code. The technical report for the approach is:
>
> Teuchos C++ Memory Management Classes, Idioms, and Related Topics
> The Complete Reference
> A Comprehensive Strategy for Safe and Efficient Memory Management
> in C++ for High Performance Computing
>
> and can be found at:
>
> http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf
>
> If someone would be willing to at least go through the abbreviated
> table of contents laid out in the Preface and provide some feedback,
> I would be greatly appreciative.

I note that there is no thread safety baked in yet.

You can use boost::range instead of a reference to vector to pass an array safely.

It isn't clear to me what your implementation offers that isn't covered by purify or library checked iterators. If you do your own allocator you need to do these things to implement a debug mode. If you use the system allocator them purify works. If you use the stl then you use their debug mode. I don't see the point of implementing your own reference counted allocator and pointer object to replace the system allocator and raw pointer when that is the case where tools like valgrind and purify work. I read your justification for why these tools are insufficient, but you didn't convince me that you have covered any cases that they would not. It seems to me that you have invented a way to do manually what valgrind does automatically. What am I missing?

Regards,
Luke


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk