Re: [boost] Re: shared_ptr/ intrusive_ptr

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-06-26 15:15:38

> > It's not a 100% perfect solution, but it's an attempt to solve the issue
> at
> > source, rather than working around it.
> >
> > Of course, you may disagree and suggest that the factory method is a
> > solution rather than a work around, and my concept is misguided - in
which
> > case I am open to persuasion :-)
>
> Persuasion:
>
> An object that needs to automatically create weak pointers to itself at
> creation time must only be allocated on the heap => its constructor needs
to
> be non-public so that the user can't create an automatic/static object =>
it
> needs to have a public factory method returning shared_ptr/intrusive_ptr
in
> order to be createable => the factory method can create the weak pointers
> after it has created the return value.

You are very persuasive ;-)
I hadn't taken the step of making my constructors non-public, so didn't
require the factory method.
I realise this makes them easier to misuse, and probably explains why I had
to bend over backward to try and make them safer... hmmmm....
I have to say I do like the idea of doing as much of this stuff at the
library level as possible (each factory method has to be tailored to the
object in question in your scheme).
But I am becoming convinced that you present a sounded design here.

> Does it make sense? :-)

Yes.

> As for the other question: yes, creating objects with an initial count of
1
> and manually calling release() is an option. There are no exception safety
> issues since addref and release don't throw.

Hmmm, you could be right (again - damn!). I was thinking along the lines of
intrusive_ptrs constructor throwing, but it looks like thats ok too... doh!
over-engineered again on my part.

> It is possible to implement an intrusive pointer that depends on an
initial
> count of one and does not addref in the constructor, but this prevents the
> arbitrary raw-to-smart conversion which is one of the strongest features
of
> intrusive counted pointers.

Yes I agree with this. The case where the initial count is 1 requires a
one-off transfer of ownership (hence my MakeShared)... hmm that sounds
familiar... if I renamed my class that wraps the aquisition by intrusive_ptr
and the ref count release something like, say, xfer_ptr it starts to look
like a concept I was working on a while back for providing auto_ptr-like
move semantics in a less surprising way. It seems the concept can be
extended to this case and fits it well. I wonder if it is worth generalising
this concept to interoperate with all, or at least most, of the boost smart
pointer types....
Now you have got me thinking.

At the moment (with the rename) I can do the following:

    shared_ptr<T> p( xfer_ptr<T>( new T ) );

However, in the meantime I think I have resigned myself to using the factory
method for creating object models with back references.

Many thanks,

[)o
IhIL..