On 6/14/06, Pierre THIERRY <nowhere.man@levallois.eu.org> 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. Slowly, Scott McMurray