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..