0

How to call the required function that returns rvalue reference(&&) to a class variable instead of one that returns const lvalue reference(const&) to a class variable. This is my sample code

class A {
    int a { 10 };

public:
    const int& get_a() const& {
        std::cout << "const lvalue ref\n";

        return a;
    }

    int&& get_a() && {
        std::cout << "rvalue ref\n";

        return std::move(a);
    }
};
    
int main() {
        std::cout << A().get_a() << std::endl; // calls rvalue reference version
    
        A a_obj;
        // how to make it call rvalue reference version?
        auto aa = a_obj.get_a(); // calls const lvalue reference version
        std::cout << aa << std::endl;
}
Harry
  • 2,177
  • 1
  • 19
  • 33
  • 2
    Convert to rvalue like `std::move(a_obj).get_a();`. – songyuanyao Dec 25 '21 at 10:16
  • Replace `a_obj.get_a();` with `std::move(a_obj).get_a();` . – Jason Dec 25 '21 at 10:17
  • @songyuanyao I know `std::move` just creates rvalue reference, but is it safe to use a_obj after `std::move` because i might use the object later. – Harry Dec 25 '21 at 10:19
  • Apply a `static_cast` to the LHS of the call. In general though, I would keep away from the approach you seem to take here, because `x.get_a()` can modify `x` in some cases and leave it as is in others. See also "Principle of Least Surprise" – Ulrich Eckhardt Dec 25 '21 at 10:19
  • @Harry It's safe. `std::move` just converts to rvalue and won't do anything more itself. – songyuanyao Dec 25 '21 at 10:24
  • @AnoopRana - No, that's true only if the object was used in a move operation like construction or assignment. A std::move on its own does not actually move, it's a (poorly) named cast. – StoryTeller - Unslander Monica Dec 25 '21 at 10:24
  • @StoryTeller-UnslanderMonica I'd argue that there is no difference between calling a method on a result of `std::move` and passing the result to a constructor/assignment. Accessing the object after both may or may not be legal depending on how the method/constructor/assignment is implemented. – HolyBlackCat Dec 25 '21 at 10:33
  • @HolyBlackCat - The point of confusion here as far as I see was whether or not calling the method is allowed because of std::move. – StoryTeller - Unslander Monica Dec 25 '21 at 10:49
  • @AnoopRana - Prove what exactly? The standard only specifies it for its own types (valid but unspecified state). Everything else is up to how language users design their own types. A type that only supports copying will always be valid after a move, because moving has no deep meaning at the core language level beyond value categories. – StoryTeller - Unslander Monica Dec 25 '21 at 10:53
  • @AnoopRana - So *your* source as an appeal to authority of some author. And you expect me to prove a negative (since that's my claim, there is no constraint on third party types) by citing *the standard*. And you throw that pompous first sentence at me about evidence, very rich. I'll give you a source that fits your standard of evidence, here it is from the horse's mouth, Howard Hinnant, who is responsible for standardizing move semantics. [*"The C++11 std::move(x) function doesn't really move anything at all"*](https://stackoverflow.com/q/21358432/817643). – StoryTeller - Unslander Monica Dec 25 '21 at 11:31
  • @AnoopRana - `std::string str = "abc"; auto&& str2 = std::move(str); cout << str;` I'm sure you can figure out why it will print `abc` reliably. But if you can't apply that to what I said, then there is really nothing I can do to help. – StoryTeller - Unslander Monica Dec 25 '21 at 11:46
  • @AnoopRana - Here's a thought, how about you go bug the Primer's authors (who wrote most of the C++11 version of the book before C++11 was fully baked and understood by many) about *their* claims instead of bugging me. The fact that a book aimed at novices tells a little lie to keep them from getting confused when practicing does not invalidate the *actual* semantics that journeyman and experts use to build their software over. – StoryTeller - Unslander Monica Dec 25 '21 at 12:00
  • @AnoopRana - The fact it was published in 2012 doesn't mean it was rewritten in the short time span since c++11's publication. And I only get annoyed only at annoying snoots who take informal back and forth and then turn and start demanding formally correct discussion when their own claims are based on (an albeit mostly helpful) imprecise book. And I'll make claims wherever I want to make claims. – StoryTeller - Unslander Monica Dec 25 '21 at 12:26
  • @AnoopRana What's the claim you want the source for? That it's not necessarily UB to interact with an object after applying `std::move` to it, depending on how you use the result of the move? If so, it's impossible to prove a negative. It's allowed because the standard doesn't forbid it. I concur with StoryTeller that the quote from C++ Primer you provided is wrong, it's a small lie made to newbies, to quickly summarize the intent of moving. If it's indeed UB, it's up to you to quote the standard here. – HolyBlackCat Dec 25 '21 at 12:40

0 Answers0