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. Raw resp. opaque pointers have one huge advantage in productive environments : They work as perfect isolators, removing any compile time dependencies. And from my point of view, compile time is what matters most, if you go productive, otherwise you end up waiting for recompiles. From: Mathias Gaunard <mathias.gaunard@ens-lyon.org> To: boost@lists.boost.org Date: 27.05.2010 14:59 Subject: Re: [boost] Review of a safer memory management approach for C++? Sent by: boost-bounces@lists.boost.org Bartlett, Roscoe A wrote:
Hello Boost developers,
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 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.
Never use owning naked pointers and only use RAII (as is required for exception-safe programming anyway) with exclusive ownership and no aliasing, and you have no problems. Usage of shared_ptr should be an exception, not a widely deployed solution to memory management issues. Shared ownership is hard to reason about, and even if you use a similar cycle-aware solution, cycles remain a real problem (they prevent deterministic ordered destruction of objects, meaning they're only applicable to certain classes of objects). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost