Re: [boost] [valid_ptr] proposing a new type of pointer object that allows validity tracking without memory management and object ownership

Subject: Re: [boost] [valid_ptr] proposing a new type of pointer object that allows validity tracking without memory management and object ownership
From: Dan Walters (dan683_at_[hidden])
Date: 2011-03-16 21:19:17

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