-
-
Save avdi/1401793 to your computer and use it in GitHub Desktop.
#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 |
...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; }
@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.
"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.
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.
Completely consistent with the C++ memory model... and completely surprising to most programmers. Especially when they accidentally type
=
when they meant==
in anif
statement.