Re: [boost] : Review of a safer memory management approach for C++

Subject: Re: [boost] : Review of a safer memory management approach for C++
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-06-08 14:03:31

Bartlett, Roscoe A wrote:
> Valgrind and purify are very useful but they will often only flag
>   there is a problem until much after the original error occurred. 
> As an example, a few months ago I was using std::multimap for the
> first time in a GCC implementation.  The documentation I found for
> std::multimap on the web was not very detailed and did not really
> explain behavior in a few important cases (I have had a hard time
> finding decent standard C++ library documentation).   I ran the code
> and it behaved in strange ways, segfaulted, etc.  I turned on the
> checked STL implementation with -D_GLIBCXX_DEBUG but it did not
> complain about anything.  I ran valgrind on it is it complained there
> was a problem in a place in the code that made no sense at all.  I
> knew the only "unsafe" code that I had written (that did not
> exclusively use the Teuchos MM classes and idioms) was the
> std::multimap code.  After more experimentation I figured out that I
> had guess the behavior of std::multimap incorrectly.  Once I figured
> out what the behavior really was, the program ran fine.  Here was a
> case where the checked STL implementation was not catching a basic
> user error and valgrind was worthless.  I just wish that I would have
> saved the state of this code in a branch or something so that I could
> show this to other people.     

I like http://www.sgi.com/tech/stl/, but it is for STLPORT so you will find some differences from gnu stl.

I never use multimap and prefer map of vectors.  

You can turn off the stl memory pool at the compile line and force it to use the system allocator to help valgrind find errors.
             
> There are people in my domain that still today will refuse to use a
> smart pointer class and insist on manipulating raw memory, even in
> brand-new code.  The cycle of undefined behavior, segfault, etc. will
> continue ...   

They are writing C code and compiling it with the C++ compiler.  Everything in the C++ language that is not C is there to help with this problem, but it only helps if people use it.  If they refuse to follow coding conventions that prevent bugs why do you expect them to use your memory checking pointers?

> Do people have experience with library allocators from MPI and TBB? 
> These are supposed to place memory more carefully but they mean that
> you can't use the allocator embedded in std::vector anymore.  

You pass the allocator at the end of the template parameter list.  They place memory carefully to prevent performance problems, not to prevent bugs.  Buffer overrun by one element may become benign in the majority of cases when you pad your allocations out to the cache line, but I wouldn't count on it.

Regards,
Luke