On 08/31/2015 07:08 PM, Niall Douglas wrote:
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.
Yes, it describes the behavior. What you describe is totally beyond me, please provide me with your goggles to cure me and the rest of the (C++) world from our myopia.
*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.
I have no clue what that even means. Must be because I am German.
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.
Ok, please provide an example other than sharing ownership to a pointer/resource that requires atomic reference counting?
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.
So it's a witch hunt now? My post was merely to inform you about what others think about what semantics a shared_ptr implies. You don't have to like it, just be aware that without a common ground of definitions, there can be no profounded technical discussion. Call it a witch hunt if you like... From your "ivory tower"-ly yours, Thomas P.S.: I am casting a spell with over 9000!
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost