Re: [boost] [shared_ptr] Best Practices - new_shared_ptr

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2006-03-24 07:22:43

Vaclav Vesely wrote:
> However the conclusion of the article is, that ok1() is better than 
> ok2() because you have to write helper functions. I don't agree. IMHO 
> ok2 IS better and the helper functions should be in the library (so the 
> uses doesn't have to write them. What do you think?

FWIW, as someone that wasn't entirely clear on the problem before 
reading the linked gotw article, I tend to agree that the helper 
function is preferable and would be a good inclusion into boost (with 
versions for each of the boost smart pointer types, of course).
AFAICS it compiles away to little more than an enforcement on sequence 
ordering (at least no more than the two step recommendation), but 
retains the expressiveness of the original intent.
I'd say it could be argued to be less preferable if you have to write 
the helper yourself every time - but if included in boost (and perhaps 
later, the standard) I can't see why it would be preferable to *not* at 
least have the option.

Also, there are some (minor) incoveniences to the two step approach. 
Other than the obvious fact that there is more typing involved, there is 
also the issue of scope. If you bring a named instance of an auto_ptr 
(or shared_ptr etc) into being, it will "hang around" until the end of 
the scope (even if now empty, in the case of auto_ptr). This may not be 
desirable, in which case you have to introduce an extra scope to contain 
it, which seems like more and more clutter to our "workaround".

Finally, even if a future standard "plugs" the loophole - this technique 
would still make code safer for older compilers.

So, yes, I agree that some sort of smart pointer factory methods would 
be ideal.

Best regards,

[)o
IhIL..