Boost logo

Boost :

From: me22 (me22.ca_at_[hidden])
Date: 2006-06-15 00:01:14

On 6/14/06, Pierre THIERRY <nowhere.man_at_[hidden]> wrote:
> But then it makes refitting code to smart pointers a pain. And if
> anything is wrong with the smart pointers, it's a pain again to remove
> them.
> Maybe in most cases, with smart pointer assignation operator, it would
> only be a matter of commenting all calls to free() or the delete
> operator and having a typedef for the pointer type and you could easily
> use smart pointers or not.
Refitting to smart pointers has to be done very carefully to prevent
multiple deletes. Making the implicit creation of shared_ptrs illegal
is a feature.

And it's easy to implement a dumb pointer wrapper with a .reset() if
it's really needed, but going back from smart pointers would also be
quite difficult, as all the releasing would have to be put back again
manually, and odds are that the orderings and such are different from
before after fixing assignment orderings to avoid multiple frees.

> But it's not possible anymore that the pointer be in the scope of the
> while() loop. Maybe that's not an issue, though.
In that case I'd use a for loop, personally. As mentioned, I wasn't
exactly sure what you were trying to do.

> Would it be OK if an assignable version of the smart pointers was
> implemented as different classes? That is, if a patch added
> assignable_shared_ptr and assignable_scoped_ptr?
You could easily implement them yourself as fairly trivial wrappers
around shared_ptr or scoped_ptr. In fact, you could probably even
template it to make assignable< shared_ptr<T> > and assignable<
scoped_ptr<T> > work.

If you have a well-written implementation and a solid use case, then
it's quite possible that it would be added.

Scott McMurray

Boost list run by bdawes at, gregod at, cpdaniel at, john at