Dear all, Rutger, Mathias, Peter, Matt, Joël Lamotte, thanks for your replies, I appreciate your input. Rutger, as I understand, intrusive_ptr<T> is a reference counting type pointer that takes shared responsibility for the memory allocation of the object it points to. Thus, the object pointed to cannot be destroyed if an intrusive_ptr to it still exists. With valid_ptr, a large part of the concept is that the programmer doesnt always want to control when the object can be destroyed. However, the programmer does always wants to know if the pointer points to a valid piece of memory. Valid_ptr is more like a normal c++ pointer than a smart pointer. It assumes no ownership of the object, it simply points to the memory. It's only feature up from a normal c++ pointer is that it can check that the object it points to is still valid memory. Matt, Valid_ptr would do a similar thing to using shared_ptr and weak_ptr. Valid_ptr could be better when very frequent access is required (very little access overhead while weak_ptr requires a little more) and it can also be less intrusive to the code as it doesnt require the code to relinquish control of memory allocation (should the programmer have his own strategy). Sometimes valid_ptr would give cleaner code, it is lighter weight and much more primitive under the hood. But shared_ptr and weak_ptr have more features and have many advantages in other cases. Perhaps weak_ptr and valid_ptr are similar in the way std::list and std::vector are similar. Similar functionality, but one is usually better than the other depending on how they are used. I understand the key difference to be that valid_ptr does not imply ownership, sometimes an advantage, sometimes disadvantage. I think the problem domain I am defining is distinctly different to that for which shared_ptr and weak_ptr is designed - valid_ptr is not concerned with remembering to delete the memory it points to, or take responsibility for this. It is only for keeping track of if the object being pointed to has been destroyed or not. I consider it a lighter weight object that is somewhere between a normal c++ pointer and a smart ptr. Peter, I agree, I am yet to come up with a MT solution that makes sense here, that needs thought. I do not understand your comment about f() indirectly causing the object to be destroyed, could you explain this a little more? if f() is a member function, surely that would involve the line "delete this;" ? I am missing something... I appreciate how strong a library the smart_ptrs are and understand the reasoning behind locking weak_ptrs in order to access them. As you explain, this is particularly awesome in a MT environment. I did comment that weak_ptr is slightly heavier weight for accessing it's value (than to valid_ptr) but appreciate that it is essential in order to ensure the object isnt destroyed in a MT environment. What I am proposing is a ptr object that doesnt consider this by design - greater performance (for accessing) (but not safe in a MT environment?). My understanding is that valid_ptr fills the gap between c++ pointer and smart_ptr. Essentially, it is just a normal c++ pointer with a thin layer of underlying code to help stop the programmer from accessing an invalid pointer. Regarding the safety issues, the valid_ptr is not as fool proof as a smart_ptr (because it doesnt manage memory assignments), but it is safer than a normal c++ pointer and used in a very similar way so maybe this is ok. Matt, Your passive_ptr concept differs from valid_ptr but your reference to semantic intent is very significant. I think that valid_ptr implies that the object being pointed to is expected to become invalid at some point, and that it is not safe to use a regular pointer. I think it also implies that the object being pointed to is owned by another object or container and not under the control of valid_ptr. An important point to understand that valid_ptr is only half of the library - the other half being valid_target. The target object is inherited or wrapped to provide a reference register (a lot like intrusive_ptrs reference count). When the object is destructed, the reference register is used to inform all the valid_ptrs pointing to that object that they are no longer valid. That is how validity is ensured. It results in light weight valid_ptrs although the target object may be heavier weight. Joël Lamotte, This is not correct. I am sorry, I have not explained this clearly enough. As stated above, the valid_ptr DOES work just like a raw pointer. It is the object that is pointed to that does all the hard work. The valid_ptr can subscribe and un-subscribe to the object it points to. The subscription list that is stored on the object that is being pointed to is used to reset all subscribed pointers when the object is destroyed. Hence, when the pointer is assigned, its value goes from NULL to the value of that object. The object also receives a subscription and knows which pointers are pointing to it. When the object is destroyed, its dtor resets all the valid_ptrs that are subscribed. Matt, I am unsure if I follow your second post. Perhaps what I have mentioned above answers this? Thank you again to all who have been kind enough to give feedback, it is much appreciated. Best wishes, Dan

Since the MT issues had already been raised, both of my comments were concerning similar-but-different cases than what you proposed. passive_ptr<> would simply indicate non-ownership, without making any assertions about object lifetime or pointer validity. The comment about nonnull_ptr<> was just riffing on Joël's comment. It might be interesting to explore the possibility of templates which parameterize both the object lifetime management policy and pointer validity (or non-null-ness, at least). Whether it would be worthwhile is a separate question. It does seem to me that one solution you might use to solve the MT problems would be to put a shared_mutex in valid_target<> and hide some locking in accesses via valid_ptr<> (i.e. put a scoped_lock in a temporary object returned by valid_ptr<>'s operators). Then, valid_target<> acquires an exclusive lock, when it's directed to delete the referenced object. Unfortunately, I don't see how that would be better than weak_ptr<>. It certainly wouldn't be any faster or lighter-weight. I can see how it would solve certain shared-ownership scenarios where you don't know, a priori, who will delete a shared object or when. But the same thing could be accomplished by using weak pointers to an object whose refcount had been manually incremented by 1. When you want to kill it, one of the referers could then manually decrement the refcount, so that it gets killed when it goes back to idle. Matt -----Original Message----- From: boost-bounces@lists.boost.org on behalf of Dan Walters Sent: Wed 3/16/2011 9:19 PM To: boost@lists.boost.org Subject: Re: [boost] [valid_ptr] proposing a new type of pointer object that allows validity tracking without memory management and object ownership

Matt,

I am unsure if I follow your second post. Perhaps what I have mentioned above answers this?

Thank you again to all who have been kind enough to give feedback, it is much appreciated.

Best wishes,

Dan

On 17 March 2011 03:33, Gruenke, Matt <mgruenke@tycoint.com> wrote: ... the possibility of templates which parameterize both the object lifetime management policy and pointer validity (or non-null-ness, at least).  Whether it would be worthwhile is a separate question. I think the issue of semantics, showing intent, suggesting behavior is very relevant. Perhaps the name subscribed_ptr describes the usage and mechanics better than valid_ptr does? Matt <mgruenke@tycoint.com> wrote: ... put a shared_mutex in valid_target<> and hide some locking in accesses via valid_ptr<> (i.e. put a scoped_lock in a temporary object returned by valid_ptr<>'s operators) ... Unfortunately, I don't see how that would be better than weak_ptr<> Right now, I agree. I think thread safety is beyond the ambitions of valid_ptr which should be intentionally light weight. On the flip side, there are plenty of MT programs out there that don't use reference counting smart pointers and get by fine. Matt <mgruenke@tycoint.com> wrote: the same thing could be accomplished by using weak pointers to an object whose refcount had been manually incremented by 1.  When you want to kill it, one of the referers could then manually decrement the refcount, so that it gets killed when it goes back to idle. valid_ptr should not be able to release it's target object by design - it is not a memory management pointer.

"Non-NULL" is different than "valid". Maybe such a thing should be called nonnull_ptr<>? In the case of passive_ptr<>, I do allow it to be NULL. While a nonnull_ptr<> would useful, it would only cover some of the cases in which I use passive_ptr<>. I don't see why you'd have to check for NULL upon copy or assignment from another nonnull_ptr<>. It only needs to check in the constructor and when the value is directly changed. In fact, aside from that runtime check and the ability to alter the value, I don't really see what it buys you over using a reference. Also, whether the value is NULL is orthogonal to ownership - I could imagine having a nonnull_shared_ptr<>, nonnull_scoped_ptr<>, etc. Matt -----Original Message----- From: Klaim - Joël Lamotte [mailto:mjklaim@gmail.com] Sent: Wed 3/16/2011 6:37 PM To: boost@lists.boost.org Cc: Gruenke, Matt Subject: Re: [boost] [valid_ptr] proposing a new type of pointer object that allows validity tracking without memory management and object ownership As far as I understand, it's only a type working like a raw pointer but with checks on assignation and copy. Those checks will only assume that the pointer don't have a NULL value, (or maybe points to an adress that i'snt possible?) is it correct understanding of this library? Joël Lamotte.