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

* Bartlett, Roscoe A, on 05.06.2010 22:47:


To summarize the extremely long document, it aims to reduce problems related to
direct use of raw pointers by

    A Preferentially wrap all raw pointers in pointer-like objects.

    B Dumb pointer-like objects perform checking in debug builds, but
      are otherwise much like raw pointers and effectively reduce to raw
      pointers in release. The main advantage seems to be to restrict
      functionality as appropriate for arrays versus single objects as
      pointees. A slight disadvantage, not mentioned, is that covariant
      function results must be manually implemented.

    C A reference counting shared pointer is used that differs from
      std::shared_ptr in differentiating between weak and strong pointer at
      /run-time/ -- there is no difference type-wise.

    D Arrays are supported, and in particular slicing, but the motivating
      discussion only refers to std::vector, not std::valarray.

    E For a debug build cyclic structures of shared pointers are detected
      at program termination.

The intent is very good, and the idea of preferentially using smart pointers /
wrapper objects is also in my opinion generally good.

That said, there are some issues, which I presume is what you'd like to know
about, so, here goes.

Concerning correctness, given the timings shown, where dereferencing of the
run-time weak-or-strong shared pointer was faster than boost::shared_ptr, I
wonder if it really does check whether the pointee still exists?

My gut feeling is that it can't possibly do that checking and be faster.

And if so then the scheme outlined, aiming to avoid problems, introduces the
problem of inadvertently dereferencing dangling pointers... And anyway, if it
/did/ check for pointee existence at each dereference, then it could introduce
very unexpected exceptions or assertions. So I think this is a Very Bad Idea.

Concerning both correctness and practical usage, this /seems/ to be very
complicated. And "complex" in software development translates to bugs (in the
client code), because when one does not fully understand something, then one is
likely to use it incorrectly. But that complexity may be a wrong impression.
Perhaps the rules for what to use when and what can convert to what and so on
can be summarized in some simpler way than big tables with all combinations?

Concerning efficiency I miss simple-'n-efficient ownership transfer with custom
deleter, like my cppx::Ownership class (see my blog).

Concerning adoption of this scheme at Sandia, or anywhere, I think it would help
if the upcoming C++0x standard was focused on more strongly and more
consideration was given to how well this will mesh with idiomatic C++0x code.
E.g. some names are, as I see it, too similar to things with different
functionality in C++0x (e.g. array, tuple), invoking the wrong associations.
Which could cause things to be used in incorrect or unsuitable ways, causing
bugs or inefficiencies or complexity.

Finally, concerning the motivating discussion throughout: there are many claims
that are not substantiated and advices based on incomplete discussion. E.g.
above I pointed out the discussion of array slices, comparing this scheme
against std::vector and raw pointers but failing to discuss or even mention the
standard library's solution std::valarray. This starts already on page 1,
stating that "The built-in C++ support for dealing with dynamic memory
allocation with 'new' and 'delete' is fundamentally incompatible with the
built-in exception handling mechanism using 'try', 'throw', and 'catch'."

I can see what you (probably) mean, and if you mean what I think you mean the
intended statement is OK, but as stated it's meaningless or just plain wrong.

Some of this (like failing to mention std::valarray) seems to be caused by being
unaware of some idioms, newfangled techniques, standard library functionality
and the upcoming C++0x standard. For example, in section 5.8.1 the document
advocates factory functions to deal with foo( SP<X>( new X( a, b) ), SP<Y>( new
Y() ) ), i.e. rewriting that as foo( newX( a, b ), newY() ). This fails to
consider a centralized solution based on argument forwarding like foo( SP<X>( a,
b ), SP<Y>() ), avoiding all those redundant & error prone factories (if you
wonder how that can be done in C++98, then see for example my blog).

And in at least one place the rationale given is just incorrect, namely in
section 5.13.2 stating that "SomeClass [...] cannot call any virtual functions
in the base class to help initialize its state in the constructors". This refers
to Sutter and Alexandrescu's C++ Coding Standards book, item 49, but I doubt
that Herb and Andrei could be so totally wrong on a fundamental issue. So it's
most probably an incorrect paraphrase of whatever they did recommend.

But most this are mere details: I presume that you're happy to have them
mentioned so that you can correct them, but they're not like showstoppers.

The two main problems I see are, as mentioned, the runtime weak-or-strong
pointers, and the apparent complexity of the scheme: both may cause bugs.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]