From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-06-26 09:24:03
From: "Phil Nash" <phil.nash.lists_at_[hidden]>
> [Nicola Musatti]
> > Peter Dimov wrote:
> > > So it seems that you can't create weak_ptr's in the object
> > > need a shared_ptr first, and you can't create a temporary shared_ptr
> > > 'this' in the constructor since it will call dispose() on block exit.
> > The solution is to use a factory object that holds a shared pointer to
> > the main object and supplies the wek pointers.
> Yes, I had been using just this method as a work-around until now. But it
> *does* seem like a work-around to me, rather than a proper solution - and
> some cases does complicate the code in ways that seem unnecessary.
> However, I believe I have solved my problem now and you can see what I am
> doing in my latest reply to Peter.
> It's not a 100% perfect solution, but it's an attempt to solve the issue
> 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 :-)
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.
Does it make sense? :-)
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk