14

I've recently started appreciating std::auto_ptr and now I read that it will be deprecated. I started using it for two situations:

  • Return value of a factory
  • Communicating ownership transfer

Examples: 

// Exception safe and makes it clear that the caller has ownership.
std::auto_ptr<Component> ComponentFactory::Create() { ... }

// The receiving method/function takes ownership of the pointer. Zero ambiguity.
void setValue(std::auto_ptr<Value> inValue);

Despite the problematic copy semantics I find auto_ptr useful. And there doesn't seem to be an alternative for the above examples.

Should I just keep using it and later switch to std::unique_ptr? Or is it to be avoided?

Community
  • 1
  • 1
StackedCrooked
  • 34,653
  • 44
  • 154
  • 278
  • 2
    I'd say stick with `auto_ptr` for whatever project you're working on, and switch whenever you start something new, so that you aren't creating complexity by mixing them together. (I'm assuming the compiler(s) you use support `unique_ptr`.) – Justin Ardini Aug 10 '10 at 14:49
  • 1
    `std::auto_ptr` is being deprecated not because it isn't useful, but because `std::unique_ptr` does everything it already does, just better. So whether you switch to `std::unique_ptr` or not, there's no reason to stop using `std::auto_ptr`. – Dennis Zickefoose Aug 10 '10 at 15:39
  • Eric Lippert wrote about this a long time ago. It's an interesting read: http://blogs.msdn.com/b/ericlippert/archive/2003/09/16/53016.aspx – Mike Caron Aug 10 '10 at 18:05
  • @Mike: I don't really see how that applies. So COM refcounting is a mess, and he wrote some illegal code which just so happened to explode when he also involved (badly written) smart pointers. Hardly tells us much about *sane* smart pointer classes used in sane C++ code. – jalf Aug 10 '10 at 20:37
  • @jalf Hey, I dunno. I'm just adding some information. – Mike Caron Aug 10 '10 at 22:30

3 Answers3

5

It is so very very useful, despite it's flaws, that I'd highly recommend just continuing to use it and switching to unique_ptr when it becomes available.

::std::unique_ptr requires a compiler that supports rvalue references which are part of the C++0x draft standard, and it will take a little while for there to be really wide support for it. And until rvalue references are available, ::std::auto_ptr is the best you can do.

Having both ::std::auto_ptr and ::std::unique_ptr in your code might confuse some people. But you should be able to search and replace for ::std::unique_ptr when you decide to change it. You may get compiler errors if you do that, but they should be easily fixable. The top rated answer to this question about replacing ::std::auto_ptr with ::std::unique_tr has more details.

Community
  • 1
  • 1
Omnifarious
  • 54,333
  • 19
  • 131
  • 194
  • But stay consistent within one project. There is nothing worse than having two types that do the same thing but with different names. – Martin York Aug 10 '10 at 16:12
  • Technically, `unique_ptr` is not a drop-in replacement for `auto_ptr`. Among other things, it changes a possible runtime crash into a definite compiler error. This is generally a good thing, so you'll probably want to do a find-replace once it is available, fixing any compiler errors this triggers. See http://stackoverflow.com/questions/3451099 – Brian Aug 10 '10 at 18:10
  • @Brian - Thank you for that link. I will include your clarification and that link in my answer in the morning. :-) – Omnifarious Aug 11 '10 at 05:24
1

deprecated doesn't mean it's going away, just that there will be a better alternative.

I'd suggest keeping using it on current code, but using the new alternative on new code (New programs or modules, not small changes to current code). Consistency is important

jcoder
  • 29,554
  • 19
  • 87
  • 130
-1

I'd suggest you go use boost smart pointers.

John Smith
  • 12,491
  • 18
  • 65
  • 111
  • 9
    They don't solve the same problem. Boost is not the answer to everything, no matter how useful it is. – Omnifarious Aug 10 '10 at 14:47
  • boost smart pointers bear certain overhead with them. shared_ptr does an extra memory allocation, intrusive_ptr requires an embedded counter. there is no good substitute for auto_ptr yet. – Maxim Egorushkin Aug 10 '10 at 15:27
  • What Omni said. None of boost's smart pointers support transfer of ownership, because the standard library already provides that functionality as well as is possible in the current standard. If `std::auto_ptr` works, using either of boost's shared pointers is almost certainly a mistake [`boost::scoped_ptr` might suffice, but those situations are relatively limited] – Dennis Zickefoose Aug 10 '10 at 15:38
  • 1
    I'm already using the boost smart pointers. For local and member variables I use scoped_ptr, for use in containers shared_ptr. However, these do not "communicate" ownership transfer. – StackedCrooked Aug 10 '10 at 17:57
  • @Maxim Yegorushkin - sometimes the extra allocation can be bypassed using boost::make_shared. – Kylotan Aug 11 '10 at 12:53