Cast auto_ptr to auto_ptr

Question

Please help me to understand the following issue.

Look at the code example below:

#include <iostream>

class Shape {
public:
  virtual wchar_t *GetName() { return L"Shape"; }
};
class Circle: public Shape {
public:
  wchar_t *GetName() { return L"Circle"; }
  double GetRadius() { return 100.; }
};

int wmain() {
  using namespace std;

  auto_ptr<Shape> aS;
  auto_ptr<Circle> aC(new Circle);

  aS = aC;
  wcout << aS->GetName() << L'\t' << static_cast<auto_ptr<Circle>>(aS)->GetRadius() << endl;

  return 0;
}

Why I am not allowed to do this:

static_cast<auto_ptr<Circle>>(aS)->GetRadius()

Compiler (MSVCPP 11):

1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory(911): error C2440: 'initializing' : cannot convert from 'Shape *' to 'Circle *'
1>          Cast from base to derived requires dynamic_cast or static_cast

@Truncheon: Are deliberately _trolling_? After months I haven't felt like this, your comment is another case of "I wish we could downvote comments!" — sbi, Dec 20 '11 at 10:44
Too bad you cannot down-vote comments.. I agree with you on the fact that std::auto_ptrs aren't always the best alternative to use, though if memory management can be handled by an object wrapping the pointer I see nothing wrong with that. The developer might then focus on the real problem he is solving, instead of having to think about dangling pointers and such. — Filip Roséen - refp, Dec 20 '11 at 10:45
@sbi we think alike.. (note, I didn't see your comment when writing mine since I didn't refresh this thread) — Filip Roséen - refp, Dec 20 '11 at 10:48
@Truncheon: thanks for typing but I've asked what I've asked for. — nickolay, Dec 20 '11 at 11:09
Guys, there's new problem. There are 2 answers (Steve Jessop and refp). They both are correct, competent and constructive. How should I choose the "Correct answer" ? — nickolay, Dec 20 '11 at 11:25
@DaddyM: you could choose on the basis of either (1) reward the person whose answer was most helpful to you, or (2) highlight (and reward) the answer that you think will be most useful to people in the future who find this question by search. — Steve Jessop, Dec 20 '11 at 11:34
Guys, I choose Steve Jessop's answer as the correct one. Really he wrote a book chapter that is very concise and comprehensive. Thank you all!! — nickolay, Dec 20 '11 at 11:38
@DaddyM: Yup. And comments are posts that are not answers. Knowing that auto_ptr is ought to be removed from the standard is good, however. — Sebastian Mach, Dec 22 '11 at 12:13
@phresnel Excuse me, I didn't understand what you've meant. Have I done something incorrect? — nickolay, Dec 22 '11 at 18:03
@DaddyM: No you havent't ;) But if you're writing programs that will stay for a longer time, then it is better to not use auto_ptr anymore. The next revision of the C++ standard will probably remove it (which is why it is declared deprecated now) — Sebastian Mach, Dec 22 '11 at 22:42
@phresnel Ok. I know.I've thought I've probably violated some forum rules. :) — nickolay, Dec 23 '11 at 07:56

Steve Jessop · Accepted Answer · 2011-12-20T11:49:41.323

auto_ptr doesn't behave the same way as a pointer in this respect. There are special rules in the language to allow Shape* to be static_cast to Circle* when Circle derives from Shape. The downcast is not entirely type-safe, since it relies on the user to provide a pointer value that actually does point to the Shape base class sub-object of a Circle, but the standard allows it for convenience. auto_ptr is "just" a library class, and has no equivalent conversion.

Even if you could do it, it would often go wrong. When you copy an auto_ptr, the original loses ownership of the resource. Your static_cast would copy the auto_ptr to a temporary, and so aS would be reset and the resource would be destroyed when the temporary is (at the end of the expression). In your example that's fine, since it's going to be destroyed at return anyway, but generally speaking you don't want to copy auto_ptr except at a function call parameter or return value, to indicate transfer of ownership from caller to callee, or vice versa.

What you can do instead is static_cast<Circle*>(aS.get())->GetRadius(), or better yet restructure your code to avoid the need for a downcast. If you know that your object is a Circle, keep it in an auto_ptr<Circle>[*]. If you keep it in an auto_ptr<Shape>, then don't rely on it being a Circle.

[*] Or, if your implementation provides them, a better smart pointer such as unique_ptr, scoped_ptr or shared_ptr. Even if your implementation doesn't provide them, there's Boost.

Very clear. Thanks. But what shall I do if I want to cast (static_cast) base to derived when using auto_ptr? I know that it can be erroneous but in this situation I know that pointer to base class object really points to the derived one. — nickolay, Dec 20 '11 at 10:38
I produced exactly the same code as refp's answer without seeing it, so it's probably right :-) — Steve Jessop, Dec 20 '11 at 10:52
Dear readers, please refer to the refp answer (below) in order to see cast to reference example. — nickolay, Dec 20 '11 at 11:41
There is new question closely connected to Steve's answer: [static_cast and temporary creation](http://stackoverflow.com/questions/8581284/static-cast-and-temporary-creation) — nickolay, Dec 20 '11 at 20:36

score 3 · Answer 2 · answered Dec 20 '11 at 10:40

You certainly don't wanna do that cast, since std::auto_ptr<T> takes ownership of the internal pointer when initialized with another instance of the class.

aS will therefore loose the pointer and your new Circle object will be destroyed at the end of the std::cout statement, since the object-pointer is now owned by a temporary.

Instead you are probably looking for something like the below:

cout << ... << static_cast<Circle*>(aS.get ())->GetRadius() << endl;

You may also cast it to a reference, as below:

cout << ... << static_cast<Circle&> (*aS).GetRadius () << endl;

Cast auto_ptr to auto_ptr

2 Answers2

Linked