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

Subject: Re: [boost] Review of a safer memory management approach for C++?
From: David Abrahams (dave_at_[hidden])
Date: 2010-06-04 14:06:13

At Fri, 4 Jun 2010 10:40:04 -0600,
Bartlett, Roscoe A wrote:
> 
> > I _will_ argue that OOP has costs to software complexity that are
> > often under-appreciated.
> 
>  [Bartlett, Roscoe A] 
> 
> Any approach can be misused, including anything you might be trying
> to advocate (but I am not 100% sure what that is exactly).
> 
> > > Note that C++ was first designed in the early
> > > 80s primarily to support #2 object-oriented C++.  I can see the
> > > reason for this bias for #3 and #4 given the nature of most of the
> > > Boost libraries and you can have that opinion if you would like.
> > 
> > I don't, so please read what I wrote and try to address that rather
> > than to your preconceived notions of my ?bias.?
> 
> [Bartlett, Roscoe A] 
> 
> I am not trying to put words in your mouth.  I am just trying to pin
> down your argument/position.  You can say that I have a "bias" for
> good software if you would like :-) 

I'm not sure what that is supposed to mean.  Isn't it safe to assume
that everyone here has that bias?

> Seriously, I am sorry if I misinterpreted you position with the
> position of others on the boost list who were arguing for a more
> template-heavy approach.  I guess that you are arguing for more of a
> stack-based approach (see below).

No, I'm not arguing for any particular approach.  I'm arguing that the
tools we have in C++ are enough to effectively handle the problems
you're trying to address with Teuchos.  But I have to admit that I
haven't read the whole paper so I may not know what all those problems
are.

> > > I would argue that the current accepted approaches to writing OO
> > > programs in C++ (i.e. #2 OO C++ features) make it too easy to create
> > > programs with undefined behavior (i.e. segfaults or worse) and as a
> > > result, the paranoia of undefined behavior in C++, memory leaks
> > > etc. lead to lots of bad programming practices and designs (see
> > > Section 1 in
> > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf).
> > 
> > Seriously?  Are you saying that a disciplined application of
> > shared_ptr, weak_ptr, new_shared, et. al when dynamic allocations are
> > called for is insufficient for most OO programs?
> 
> [Bartlett, Roscoe A] 
> 
> As argued in the Teuchos MM document
> 
>     http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf
> 
> these boost classes are a good start but they are *not* sufficient
> to build a safe and effective memory management system that
> encapsulated *all* raw pointers.  What is missing for single
> objects, as described in Section 5.14 and other sections, is the
> Teuchos::Ptr class.  Without integrating a class like Ptr in with
> the reference-counted pointer classes, you can't build a safe and
> effective memory management system in C++ that comes closer to
> eliminating undefined behavior.  

Yes, wrapping every pointer and adding debug-mode-only checks for
invalid usage is one way to help programmers debug their code.  In a
strict sense, though, eliminating undefined behavior requires keeping
the checks on in optimized code.

By the way, I actually like undefined behavior.  It creates a clear
boundary between valid and invalid usage.  If all usages have defined
behaviors, then neither the compiler nor runtime tools are allowed to
interfere with such usages to help the user detect bugs.  So I'm not
in favor of eliminating it, at least not without some other measure of
what's illegal.

> Also, as described in Section
> 5.9.2, separating weak_ptr from shared_ptr is not ideal from a
> design perspective since it reduces the generality and reusability
> of software (see the arguments for this in the document).

I see the arguments.  They boil down to, “there are complex cases
where weakness needs to be determined at runtime rather than compile
time.”  IMO any design that uses reference counting but can't
statically establish a hierarchy at ownership is broken.  Even if the
program works today, it will, eventually, acquire a cycle that
consists entirely of non-weak pointers, and leak.  So that *shouldn't*
be convenient to write, so it's a problem with Teuchos that it
encourages such designs.  The fact that shared_ptr and weak_ptr are
different types is a feature, not a bug.  Furthermore if you
really-really-really-really need to do that with boost, it's easy
enough to build a type that acts as you wish
(e.g. boost::variant<shared_ptr<T>, weak_ptr<T> >).

> Did you read at least the sections called out in the reduced table
> of contents given in the Preface?  I think these sections should
> address all of these questions (and more).

I am afraid I haven't had time, and probably won't until the end of
next week.

> > > When runtime performance or other issues related to dynamic
> > > allocations and classic OO are not a problem, classic OO C++
> > > programs using runtime polymorphism are typically superior to highly
> > > templated C++ programs using static polymorphism
> > 
> > Straw man; I'm not arguing for ?templated C++ programs using static
> > polymorphism.?
> 
> [Bartlett, Roscoe A] 
> 
> Okay, the runtime vs. compile-time polymorphism debate is another
> issue (but a very important one).  Are you instead arguing for a
> static and stack-based approach to programming?  

No, I'm arguing for a value-based approach.  If you're strict about
it, you even turn references into values using type erasure… although
doing so is often unfortunately so tedious that I wouldn't insist on
it.

See http://stlab.adobe.com/wiki/index.php/Papers_and_Presentations,
particularly

* Classes that work video: http://my.adobe.acrobat.com/p53888531/

* Thread Safety pdf (expanded version of slides in “Classes that
  work”):
  http://stlab.adobe.com/wiki/index.php/Image:2008_09_11_thread_safety.pdf

* A Possible Future of Software Development video:
  http://www.youtube.com/watch?v=4moyKUHApq4

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com