Boost logo

Boost :

Subject: Re: [boost] Review of a safer memory management approach for C++
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2010-06-07 13:32:15

Hi Bartlett,

Just for the record and since your statements below are about general
experiences with large scale C++ projects, let me put my own experiences in
context: I had been architecting, designing and implementing large-scaled
projects from the early 90's. The largest of which accounts for 160K of C++
code, which in fact I wrote almost entirely myslef.
Again this is just to put the comments based on my experience in persective.

> These types of experiences have
> lead many C++ teams to code C++ with a (justified but unfortunate) paranoia
> about the use of memory in C++ that has all kinds of bad consequences

I think that those memory problems are funtamentally rooted at a design issue.

In the mid 90's I used to developed best practices and utilities for sane memory
management (and other sanity requirements), in the same spirit of the paper you
presented (I did read it btw). I even implemented custom allocators, based on
class-specific memory pools, and mandated that every object should obey a strict
allocation-deallocation protocol.

Simply defining a new class on my system required the use of a macro-based DSL,
something like "DEFINE_DERIVED_OBJECT(Foo,Base). Likewise, object graphs had to
be very carefully spelled with my DSL, as in "INCLUDE_SUBOBJECT(Bar)", and so on..

This forced everyone in the team, year after year, to learn a language on top of

In the long end, however, I realized I was just overengineering the problem way
too much, putting a big burden on the team and making it difficult for newcomers.

When C++ evolved I found new, much simpler ways to solve the same problems, and
in particular, memory problems: using smart pointers (even long before
boost::shared_ptr came alone). Once I started using smart pointers I never
looked back, and I never again, ever, had to spend a single minute on a memory leak.

> Come one, at least some people on this mail list must have had similar
> nightmare experiences in trying to track down and diagnose hard memory misuse
> errors in C++ that took days of effort to resolve (even with the help of
> tools like valgrind and purify).
Before I started using smart pointers, yes.
After that, no.. never again.

> And again, tools like valgrind and purify will *never* catch semantic misuse
> of memory (i.e. allocating a big chunk of memory and then breaking it up to
> be used to construct different objects and array of objects). The Teuchos MM
> classes will catch most semantic misuse of memory in a way that no tool like
> valgrind and purify every can (because they don't know the context of your
> program, they only know that any read/writes in a big block of memory that
> you allocated look okay). I think this is a big deal in catching
> hard-to-find defects that are not (technically speaking) memory misuse
> defects but are program defects none the less.
I totally fail to see why this design mistakes (wrong allocation pattern) should
be detected by a framework? These are design issues and should be deal with at
that stage. Surely any team can be trained not to make such mistakes.


Fernando Cacciola
SciSoft Consulting, Founder

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