Is that an obfuscated retry?
-
@Zecc said in Is that an obfuscated retry?:
I'm going to hell
Yes, that brace-on-its-own line in the Wtf class is definitely a damnation-worthy offence.
Making true(x) and false(x) not return the opposite of each other is a special touch. I really don't want to know what the meaning of if(a) { ... } or if(!a) { ... } are. (Or can you even do that without an implicit cast-to-bool?)
-
@dkf said in Is that an obfuscated retry?:
@PleegWat said in Is that an obfuscated retry?:
Needless to say this is dangerous, because two truthy values bitwise anded together can give a falsey result.
The whole purpose of the
&
operator is for doing bit masking. That is its job.Well, yes. So if people think "& is the same as && but always evaluates both arguments" which is apparently true in C# in some contexts, then end up writing
9 & 6
, and they've got a bug.@JBert said in Is that an obfuscated retry?:
In C# there is no "truthy", there's only bool.
A value which, if cast to boolean, is true (or false). You know what I mean.
-
@PleegWat said in Is that an obfuscated retry?:
So if people think "& is the same as && but always evaluates both arguments" which is apparently true in C# in some contexts, then end up writing 9 & 6, and they've got a bug.
They get what they deserve for converting to
bool
after their attempt at using a Boolean operator instead of beforehand. If you convert before operating it works.
-
@Unperverted-Vixen said in Is that an obfuscated retry?:
@PleegWat said in Is that an obfuscated retry?:
So if people think "& is the same as && but always evaluates both arguments" which is apparently true in C# in some contexts, then end up writing 9 & 6, and they've got a bug.
They get what they deserve for converting to
bool
after their attempt at using a Boolean operator instead of beforehand. If you convert before operating it works.Sounds more like “use &” was bad advise to begin with, which is what @PleegWat was talking about.
-
@topspin I don't think that using
&
is bad advice, though. If you're trying to get a Boolean result, make sure the inputs arebool
s and everything will be fine.
-
@Unperverted-Vixen said in Is that an obfuscated retry?:
@topspin I don't think that using
&
is bad advice, though. If you're trying to get a Boolean result, make sure the inputs arebool
s and everything will be fine.I'd rather say, if you need both sides evaluated, make it explicit by storing the results in local variables first. Then it doesn't matter which operator you and them with.
-
@Unperverted-Vixen said in Is that an obfuscated retry?:
I don't think that using & is bad advice
At the very least, it's extremely unintuitive. The operator is meant for bit masks, so using it for anything else (including bools) is a as far as I'm concerned.
@PleegWat said in Is that an obfuscated retry?:
I'd rather say, if you need both sides evaluated, make it explicit by storing the results in local variables first.
^ This.
-
@Zecc said in Is that an obfuscated retry?:
Yes, when dealing with lossy conversions, order of operations matters. C# is a strongly-typed language. 1 and 4 are not booleans; they're integers. When you coerce a 32-bit integer down to a 1-bit boolean, you're throwing out 31 bits of potentially relevant information. So 1 and 4 both resolve to
true
, but you can't taketrue
and get a 4 out of it.TLDR: if you're mixing bool conversions and bitwise operations, you're .
-
@PleegWat said in Is that an obfuscated retry?:
So if people think "& is the same as && but always evaluates both arguments" which is apparently true in C# in some contexts, then end up writing 9 & 6, and they've got a bug.
Who thinks that? They're fundamentally different things. It's unfortunate that they look so similar, and even more unfortunate that you're allowed to apply
&
to bools when it's a bitwise operator intended for integers. If they could fix that, it would clear up a lot of the confusion.
-
@Mason_Wheeler For that matter, why is there no
&&=
operator? Then they could have made applying&
and&=
to boolean values an error and this whole mess would have been moot.
-
@dkf You could write
if (var) var = value
forvar &&= value
, andif (!var) var = value
forvar ||= value
, but it wouldn't win a beauty contest even after adding your favourite flavour of braces and newlines.
-
@PleegWat Yes… except you've got a double evaluation of the meaning of
var
. Which doesn't matter for simple variables, but for arrays with complex and side-effect-ful expressions calculating the index…Language design has some fun gotchas!
-
@PleegWat said in Is that an obfuscated retry?:
@dkf You could write
if (var) var = value
I just know some smartass compiler has an innocuous looking flag that will aggressively optimize exactly this kind of statements without preserving the side effects.
-
@Gąska said in Is that an obfuscated retry?:
I just know some smartass compiler has an innocuous looking flag that will aggressively optimize exactly this kind of statements without preserving the side effects.
None of the modern compilers (from the last 20 years or so) do that; they're very careful with side effects and are theory-based so that problems like that don't happen. In short, one of the major correctness criteria for a compiler is that the trace of side-effects is right. Other parts might get radically changed though...
-
@Zecc E_FILE_NOT_FOUND_NOT_FOUND
-
@dkf said in Is that an obfuscated retry?:
@PleegWat Yes… except you've got a double evaluation of the meaning of
var
. Which doesn't matter for simple variables, but for arrays with complex and side-effect-ful expressions calculating the index…Language design has some fun gotchas!
But in contrast to
var = var || value
, the order in which the side effects occur is defined!
-
@PleegWat said in Is that an obfuscated retry?:
But in contrast to
var = var || value
, the order in which the side effects occur is defined!In sane languages (so not C or C++) the order of evaluation, and hence the order of any side effects, that order is defined. (Before anyone makes this old mistake, the order of evaluation is nothing to do with operator associativity; associativity is about how you build the parse tree, whereas evaluation order is about how you traverse the parse tree.)