Although unique_ptr guaranteed to store nullptr after move, it still is pointing to the object?

Question

I've tested following code with GCC 5.2 (C++11):

#include <iostream>
#include <memory>

struct Foo
{
    Foo()      { std::cout << "Foo::Foo\n";  }
    ~Foo()     { std::cout << "Foo::~Foo\n"; }
    void bar() { std::cout << "Foo::bar\n";  }
};

void f(const Foo &)
{
    std::cout << "f(const Foo&)\n";
}

int main()
{
    std::unique_ptr<Foo> p1(new Foo);  // p1 owns Foo
    if (p1) p1->bar();

    {
        //p1->bar();
        std::unique_ptr<Foo> p2(std::move(p1));  // now p2 owns Foo
        f(*p2);
        p1->bar();
        if(p1==nullptr)
        {
            std::cout<<"NULL"<<std::endl;
        }
        p1 = std::move(p2);  // ownership returns to p1
        std::unique_ptr<Foo> p3;
        p3->bar();
        std::cout << "destroying p2...\n";
    }

    if (p1) p1->bar();

    // Foo instance is destroyed when p1 goes out of scope
}

So now my question is, although p1 is guaranteed to be nullptr after move operation, it seemed still is pointing to the previous object?

Edit: Yes, I'm asking why p1->bar(); still work given p1 already moved while bar() is not static function. As everybody pointed out, undefined behavior can cause anything to happen. I've been running into enough undefined behavior nowadays... I would appreciate if somebody can point me to a collection of common undefined behaviors in C++11. Thanks in advance.

Declare the member functions `virtual` and you'll have a better change of it crashing. Then run it your app with a debugger attached and watch the internals of `std::unique_ptr`. — Captain Obvlious, Nov 30 '15 at 18:36
Can you simplify this to make it clearer what you're actually asking about? — Lightness Races in Orbit, Nov 30 '15 at 18:37
Are you asking why `p1->bar();` works after `std::unique_ptr p2(std::move(p1));`? — NathanOliver, Nov 30 '15 at 18:39
What behavior were you expecting? Under all circumstances, `Foo::bar` always does precisely the same thing. — David Schwartz, Nov 30 '15 at 18:41
Sorry for not making it clear. Yes, I'm asking why p1->bar(); works after std::unique_ptr p2(std::move(p1)); — Jokies, Nov 30 '15 at 19:06
There is not a list of undefined behaviours. There is a list of defined ones. :) [inb4 yes some UB is called out in the standard] — Lightness Races in Orbit, Nov 30 '15 at 19:28

score 6 · Answer 1 · edited May 23 '17 at 12:07

I assume you are referring to this:

std::unique_ptr<Foo> p2(std::move(p1));  // now p2 owns Foo
p1->bar();

and that it outputs "Foo::bar"?

Well, what should it do instead? You are dereferencing an invalid pointer. Anything can happen.

In this case, since you're not accessing any members of the non-existent Foo, you'd be bloomin' lucky to get a crash here (because, at a lower-level, no actual "physical" dereferencing of 0x0 need occur).

But it doesn't change the fact that what you're doing is wrong.

Although unique_ptr guaranteed to store nullptr after move, it still is pointing to the object?

1 Answers1

Linked