C ++右值引用行为（具体示例）

Question

I'm currently trying to get libc++ to compile and run with MSVC. In doing so I encountered a nasty bug (at least what I think is a bug) which has taken me a while to pin down. I have the following repro code:

int globalInt = 666;

class mini_move_iterator
{
public:

    mini_move_iterator(int* i) : __i(i){}

    int&& operator*() const
    {
        return static_cast<int&&>(*__i);
    }

    int* __i;
};

void foo(int&& rval)
{
    // Smash stack
    char stackUser[1000];
    for (int i = 0; i < 1000; ++i)
        stackUser[i] = 0xff;

    rval += 1;
}

int main()
{
    mini_move_iterator mmi(&globalInt);
    foo(*mmi);
    return 0;
}

I have a few questions:

1) Is this legal, ie have I avoided straying into the realms of undefined behaviour (it is certainly syntactically legal)?

2) What is the expected value of the global variable globalInt after foo returns (undefined may be an acceptable answer)?

EDIT:

I should have made clear that this isn't working in VS with MSVC 12. In foo the variable rval is pointing to a temporary on the stack and thus the global variable is never incremented.

The temporary is created in int&& operator*() const. If I replace:

return static_cast<int&&>(*__i);

with

return std::move(*i);

then all is well. Using a C-cast also causes the temporary to be created.

Answer 1

1) Is this legal, ie have I avoided straying into the realms of undefined behaviour (it is certainly syntactically legal)?

You are so, so close. __i is a reserved identifier, and the conversion of 0xff to char is likely implementation-defined. Other than that, this code is valid and the behavior is well-defined.

2) What is the expected value of the global variable globalInt after foo returns (undefined may be an acceptable answer)?

667 . The reference returned by static_cast<int&&>(*__i) binds directly to *__i - ie, globalInt . No temporary should be created. The applicable rule, in [expr.static.cast]/p3, has remained substantially the same since C++11, so you are definitely seeing a compiler bug here.

It looks like this bug has been fixed in the next version of VC++, based on testing on http://webcompiler.cloudapp.net/ .

Answer 2

In The C++ programming language (4th edition) , Stroustrup states (§7.7.2, pg. 195):

[...] the standard library provides a move() function: move(x) means static_cast<X&&>(x) where X is the type of x .

More precisely, from the C++11 standard (iso.20.2.3):

template <class T> typename remove_reference<T>::type&& move(T&& t) noexcept; Returns : static_cast<typename remove_reference<T>::type&&>(t) .

If your type T is an int, std::move() and static_cast<int&&>() are exactly the same thing.

So, if MSVC gives different results when switching from one to another, it's clearly a bug.