Smart pointer libraries other than Boost?

[mczard]

Do you know about any other smart pointer libraries? I have found only
three: Boost, Loki and Yasper, but I think no one of these is perfect.
If I don't find more, I will probably have to write one by myself.

 

[Lutz Altmann]

Do you know about any other smart pointer libraries? I have found only
three: Boost, Loki and Yasper, but I think no one of these is perfect.
If I don't find more, I will probably have to write one by myself.

what special-functionality that is not provided by these libraries
do you need ?

lutz altmann

 

[Vaclav Haisman]

Do you know about any other smart pointer libraries? I have found only
three: Boost, Loki and Yasper, but I think no one of these is perfect.
If I don't find more, I will probably have to write one by myself.

TR1 smart pointers? Though I hear they are very similar to Boost's ones.

 

[mczard]

what special-functionality that is not provided by these libraries

do you need ?

I am thinking about (writing) a library, which would allow:

- one pointer having ownership, many others just "observing"
- in debug mode, reference counting for the observers
- one shared (reference counted) pointer type automatically
chosing between intrusive and non-intrusive policy depending
on whether the pointed object's class have appropriate methods
(e.g. T::add_ref, T::remove_ref);
- explicit ownership passing instead of the destructible
copy for type of pointers with only one owner
- a pointer type assuring uniquness (being the only pointer
to the object)

I think, I would also choose very short names for the smart
pointer types. My choice is:

- unq<T> // unique pointer
- own<T> // the only owner, ref(erences) may exist
- shr<T> // shared, appropriate for collections, ref(erences) may
exist
- ref<T> // observing only reference, not owning
- val<T> // value type with smart pointer syntax

As you can see, I have some quite good idea about what
I am expecting. And this is something I am going to create,
but I am just checking if this approach haven't been
implemented yet.

 

[James Kanze]

(e-mail address removed) a écrit :

I am thinking about (writing) a library, which would allow:

- one pointer having ownership, many others just "observing"

That's tricky. The problem is that you don't know where the
other pointers are, so you don't know how to eliminate them. I
have a ManagedPtr class which does this, and boost has its weak
pointers, but in practice, I rarely find either to be useful.
Both just null the "observing" pointer---they don't remove it
from a container, if that's where it, and they don't tell the
owner of the "observing" pointer that it now has to look for a
back up solution.

[...]

- explicit ownership passing instead of the destructible
copy for type of pointers with only one owner

That sounds a bit like std::auto_ptr. Of all the smart pointers
at my disposition, it's definitely the one I use the most.

- a pointer type assuring uniquness (being the only pointer
to the object)

And that sounds like boost::scoped_ptr. Also very useful.

I think, I would also choose very short names for the smart
pointer types. My choice is:

- unq<T> // unique pointer
- own<T> // the only owner, ref(erences) may exist
- shr<T> // shared, appropriate for collections, ref(erences) may
exist
- ref<T> // observing only reference, not owning
- val<T> // value type with smart pointer syntax

You like obfuscation, I see. Don't want the reader to
understand what you're doing. That can be fun, but it's not
recommended in a professional context.

 

[mczard]

- one pointer having ownership, many others just "observing"

That's tricky. The problem is that you don't know where the
other pointers are, so you don't know how to eliminate them. I
have a ManagedPtr class which does this, and boost has its weak
pointers, but in practice, I rarely find either to be useful.
Both just null the "observing" pointer---they don't remove it
from a container, if that's where it, and they don't tell the
owner of the "observing" pointer that it now has to look for a
back up solution.

I will know where the other pointers are - these will be not
not trackable T*, but special trackable ref<T>. I think it
is good idea to have two reference counters - one for owning
pointers, second (in debugging mode) for observing pointers.

That sounds a bit like std::auto_ptr. Of all the smart pointers
at my disposition, it's definitely the one I use the most.

So do I, but auto_ptr does use the destructible copying,
which I do not like, as it makes code counter intuitive.

And that sounds like boost::scoped_ptr. Also very useful.

I want to have possibility to create observing pointers to
the 'unq'-pointed objects, but these obserevers will only
be temporary and whenever a 'unq' pointer is accessed, its
second reference counters should be 0.

You like obfuscation, I see. Don't want the reader to
understand what you're doing. That can be fun, but it's not
recommended in a professional context.

I think short names are good for the most commonly used
pieces of a language. Existing smart pointer libraries
require much more typing and horizontal screen space, where
it is most critical - in function headers.

 

[James Kanze]

I will know where the other pointers are - these will be not
not trackable T*, but special trackable ref<T>.

You'll know the address of the other pointers, but you still
won't know where they are, e.g. in an std::set or an
std::vector, for example.

I think it is good idea to have two reference counters - one
for owning pointers, second (in debugging mode) for observing
pointers.

That's the usual solution in this case. In practice, I've not
found such pointers very useful, however.

So do I, but auto_ptr does use the destructible copying,
which I do not like, as it makes code counter intuitive.

Yes. It's really only for special cases (like passing the
object to another thread). But most of the other cases are
handled directly with raw pointers.