Review of a safer memory management approach for C++?
in [C++]
|
Prev: Is it valid to assign a reference from a ternary expression (i.e. operator ?:)
Next: Optimize integer program in speed
From: Bartlett, Roscoe A on 5 Jun 2010 05:47 Hello, I am interested in finding one or more individuals who are knowledgeable about memory management in C++ (and especially of the reference-counting approach taken by classes like boost::shared_ptr and boost::weak_ptr) to review an idea for a comprehensive approach to safer memory management in C++ that encapsulates all raw C++ pointers in high-level code but does not require user code to be templated. The technical report for the approach is: Teuchos C++ Memory Management Classes, Idioms, and Related Topics The Complete Reference A Comprehensive Strategy for Safe and Efficient Memory Management in C++ for High Performance Computing and can be found at: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf If a few knowledgeable people would be willing to at least go through the abbreviated table of contents laid out in the Preface and provide some feedback, I would be greatly appreciative. Please at least read the sections listed in the abbreviated table of contents in the Preface before responding as most questions/issues should be addressed there. Thanks, - Ross P.S. Please make sure and respond to me personally (rabartl(a)sandia.gov) as I am not signed up for this list. { The group charter specifically says: "It is generally also considered unsocial to ask for e-mail answer: a newsgroup is a place for multilateral discussions and trying to route answers to a personal e-mail address defeats this principle. *Do not ask for e-mail responses.*" -mod } P.S. If there is a better list to send this too, please let me know. ----------------------------------------------------------------------- Dr. Roscoe A. Bartlett Sandia National Laboratories Department of Optimization and Uncertainty Estimation Trilinos Software Engineering Technologies and Integration Lead (505) 844-5097 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Goran on 8 Jun 2010 02:48 On Jun 5, 10:47 pm, "Bartlett, Roscoe A" <raba...(a)sandia.gov> wrote: > Hello, > > I am interested in finding one or more individuals who are knowledgeable > about memory management in C++ (and especially of the reference-counting > approach taken by classes like boost::shared_ptr and boost::weak_ptr) to > review an idea for a comprehensive approach to safer memory management > in C++ that encapsulates all raw C++ pointers in high-level code but > does not require user code to be templated. The technical report for > the approach is: > > Teuchos C++ Memory Management Classes, Idioms, and Related Topics > The Complete Reference > A Comprehensive Strategy for Safe and Efficient Memory Management > in C++ for High Performance Computing > > and can be found at: > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > If a few knowledgeable people would be willing to at least go through > the abbreviated table of contents laid out in the Preface and provide > some feedback, I would be greatly appreciative. > > Please at least read the sections listed in the abbreviated table of > contents in the Preface before responding as most questions/issues > should be addressed there. Wow, that's a lot of commandments and quite a bit of abstractions that support them! (IOW, it's not simple). But it looks promising, because it delves into heap pointer ownership issues, which is THE bane of C++ coding (or, as a witty guy once said, "in C++, OOP means object ownership protocols"). The problem with following your righteous path :-), in my mind, is two fold: 1. novices will fail to understand what's it all about 2. more knowledgeable people might refuse to use the library because they find it constraining ( due to the need to follow commandments ;-) ). I would guess that the key issue might be how strong error detection is in debug builds. It must excel, especially to show what's wrong to casual first-time users. How's that for a poorly informed opinion? ;-) Goran. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach on 8 Jun 2010 14:23
* Bartlett, Roscoe A, on 05.06.2010 22:47: > > I am interested in finding one or more individuals who are knowledgeable > about memory management in C++ (and especially of the reference-counting > approach taken by classes like boost::shared_ptr and boost::weak_ptr) to > review an idea for a comprehensive approach to safer memory management > in C++ that encapsulates all raw C++ pointers in high-level code but > does not require user code to be templated. The technical report for > the approach is: > > Teuchos C++ Memory Management Classes, Idioms, and Related Topics > The Complete Reference > A Comprehensive Strategy for Safe and Efficient Memory Management > in C++ for High Performance Computing > > and can be found at: > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > If a few knowledgeable people would be willing to at least go through > the abbreviated table of contents laid out in the Preface and provide > some feedback, I would be greatly appreciative. > > Please at least read the sections listed in the abbreviated table of > contents in the Preface before responding as most questions/issues > should be addressed there. 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. > ----------------------------------------------------------------------- > Dr. Roscoe A. Bartlett > Sandia National Laboratories > Department of Optimization and Uncertainty Estimation > Trilinos Software Engineering Technologies and Integration Lead > (505) 844-5097 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! ] |