public
Created

Function return as lvalue in C++

  • Download Gist
assign_to_return.cpp
C++
1 2 3 4 5 6 7 8 9 10 11 12 13
#include <iostream>
 
int& foo() {
static int pointless_static_var = 23;
return pointless_static_var;
}
 
int main(int argc, char** argv) {
std::cout << "foo() = 42: " << (foo() = 42) << std::endl;
}
 
// Outputs:
// foo() = 42: 42

Completely consistent with the C++ memory model... and completely surprising to most programmers. Especially when they accidentally type = when they meant == in an if statement.

...you can also do this with a plain local variable, but my compiler at least has the sense to issue a warning in that case.

You should be able to do an assignment on the return value if it's a reference though. Instead of the pointless_static_var you could be modifying the value of something meaningful. It's an odd language construct, but could reduce some code duplication in writing getters and setters.

And this is why I always put my constants on the left-hand side when performing equality comparisons

if (42 = foo()) { std::cout << "compiler error" << std::endl; }

On Mon, Nov 28, 2011 at 4:35 PM, Tim Pease
reply@reply.github.com
wrote:

And this is why I always put my constants on the left-hand side when performing equality comparisons

I've always disliked how that looks, but I can't deny the logic of it.

@clifton: yeah, it's totally legit, it just surprises people. I don't think I'd ever use it for a getter/setter, but there are reasons to have it there.

I've always disliked how that looks, but I can't deny the logic of it.

Actually, it can be important to follow this general pattern in other languages too. Another classic example in ruby, of doing equality comparisons, is that the equality 'operator', being just a method dispatch, you want to execute on developer supplied data not user supplied data, as that's more deterministic. In short, exactly as above, put your 'constants' (even if that's just your "baseline object") on the left hand side to increase the likelihood of deterministic and expected dispatching.

Yeah, it's particularly important with the threequals (===) since
that operator is rarely symmetric.

"constants on the left-hand side when performing equality comparisons"

Some people call those "Yoda-assignations", for obvious reasons.

My only complains are: 1) They don't look very nice and 2) You don't always have a constant to compare - you could do foo() = bar(). Help you Yoda will not on that one.

Yoda. I love it!

A similar argument is applicable in JavaScript-land, where I see many (particularly nodejs) programmers use comma-first variable declaration.

var ruby = "is pretty cool"
  , yoda = "not so pretty think yoda does"

This type of notation will trigger syntax errors when you make a mistake, which is preferable to creating globals accidentally.

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.