On 31 Aug 2015 at 17:18, Thomas Heller wrote:
I don't know why you and the HPC crowd are conflating shared_ptr with shared ownership. It an atomic safe reference counting implementation which provides no guarantees to its pointee.
I find it personally unfortunate that C++ decided to call it shared_ptr because of the word "shared" in the name, because it really isn't what its name says.
From ISO/IEC 14882:2014:
20.9.2 Shared-ownership pointers [...] 20.9.2.2 Class template shared_ptr The shared_ptr class template stores a pointer, usually obtained via new. shared_ptr implements semantics of shared ownership; the last remaining owner of the pointer is responsible for destroying the object, or otherwise releasing the resources associated with the stored pointer. A shared_ptr object is empty if it does not own a pointer.
'nuff said.
An excellent example of how theory based code design can introduce a certain myopia in its adherants which leads to certain design rigidities. The ISO standard tries to describe behaviour guarantees rather than implementation algorithms that must be used, and it does that above for shared_ptr. *IF* shared_ptr were implemented on ANY solution not using an atomic reference count, I could see a strong rationale for considering shared_ptr as the thingy which abstracts some of shared ownership. But the reality is that on every implementation I'm aware of, it's an atomically incremented and decremented reference count. I *could* go roll my own reference count solution for AFIO. But std::shared_ptr is well tested, well supported, I would assume well optimised, and does everything I need. So I grabbed the standard atomic reference count implementation which comes in the STL and bent it to my needs, and I get on with life. I would like to once again reiterate that AFIO exposes its use of shared_ptr as afio::handle_ptr. You, the AFIO end user, need not concern yourself with what kind of pointer handle_ptr is. You simply need to accept that it behaves like any smart pointer. I might change afio::handle_ptr to be something else at some future point, and your code need not concern itself about that. This witch hunt over my use of shared_ptr I think is done now. I've proven its overhead is inconsequential in AFIO's use case. I think we can accept this design decision is not important and move on now. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/