Boost logo

Boost :

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

At Tue, 1 Jun 2010 12:47:33 -0600,
Bartlett, Roscoe A wrote:
> Ingo, Mathias, and David,
> Sorry I missed your responses. It was not sent to me personally and
> I am only signed up for boost summaries.
> Is there some forum where I can present the approach described in:
> and have an opportunity to discuss the various issues with
> interested parties and leaders in the C++ community? I am not sure
> the discussions on this mail list have adequately addressed the
> issues.

The comp.lang.c++.moderated newsgroup seems like a good bet.

> > From: David Abrahams <dave_at_[hidden]>
> > To: boost_at_[hidden]
> > Subject: Re: [boost] Review of a safer memory management approach for
> > C++?
> > Message-ID: <m24ohtgpbu.wl%dave_at_[hidden]>
> > Content-Type: text/plain; charset=US-ASCII
> >
> > At Thu, 27 May 2010 20:02:45 +0200,
> > Ingo Loehken wrote:
> > >
> > > if I understand "hard to reason about" in the right why : like there
> > > is no need for shared ownership at all, this also means that there
> > > is no use for COM Programming - and of course there is.
> >
> > I think you don't understand it the right way. Shared ownership (at
> > least in the presence of mutation) is hard to reason about because
> > seemingly-local modifications can have non-local effects.
> [Bartlett, Roscoe A]
> Yes, but let's focus on the "essential complexity" of object sharing


> and not get bogged down in the "accidental complexity" of memory
> management. The approaches described in
> make explicit the "essential complexity" of object sharing while
> trying to eliminate the "accidental complexity" of memory management
> (see Section 6.1 in

I'm all for making essential complexity obvious and eliminating
accidental complexity, but I'm not sure I see a compelling example
that Teuchos does that, at least not when compared with what I
consider normal state-of-the-art C++ programming, which is mostly
value-based, dynamic allocations are rare, and those that occur are
immediately managed, e.g. by appropriate smart pointers.

> Trying to over design a program to avoid all shared ownership is
> what make C++ programming so unproductive and has all the negative
> consequences described in Section 1 in:
> Designs with object sharing can be much less complex overall than
> designs with sharing. You just need decent tools to detect circular
> reference problems (and that is what the Teuchos::RCP class has).

Well, I fundamentally disagree with all of the above. Overuse of
runtime polymorphism, thus dynamic allocation, and thus shared
ownership (it's almost an inevitable progression) is one of the things
that has made C++ programming unproductive, and those people I know
who most zealously avoid it tend to be more productive than everyone
else. IMO.

In my experience, designs with object sharing tend to increase
complexity in all kinds of ways beyond the memory management issues
that you describe. Perhaps the most important way is, they tend to
obscure the overall computation being performed by hiding it in
networks of interacting objects.

I would like to see an example of a design with shared object
ownership that is “much less complex” than all other functionally
equivalent designs that eschew shared ownership. I'm not saying such
applications don't exist, but IME they are rare, and a concrete
example would help to bring this whole discussion back to earth.

Dave Abrahams
BoostPro Computing

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