51–58 of 58 posts
I sometimes wish that x * y would short circuit on x = 0. Just because you could.
Since 1d = 01b and 2d = 10b...
1 AND 2 = 01 AND 10 = 00 = 0
1 OR 2 = 01 OR 10 = 11 = 3
I am not a programmer, but it seems to me the logical thing to do would be to operate on the binary values of 1 and 2. Since 1d = 01b and 2d = 10b... 1 AND 2 = 01 AND 10 = 00 = 0 1 OR 2 = 01 OR 10 = 11 = 3
I sometimes wish that x * y would short circuit on x = 0. Just because you could.
You mean, like, in the compiler? If x is actually a macro that expands to zero, that will (or at least should, for a sufficiently smart compiler) happen. Otherwise, I can’t imagine a runtime check of this being appreciably faster than hardware multiply. Right?
E.g. in Haskell, it would be possible to do this safely, because it is guaranteed by the type system that there are no side effects. However, even with literal 0 in the code the other operand still gets evaluated.
Earlier quoted context omitted.
This is commonly seen in Perl and PHP with stuff like launchMissiles() or die('failure');
Ugh, `or` is mostly useless in PHP. That code is identical to: launchMissiles() || die('failure');
Also, using or instead or || for these types of things is more readable since it makes your intent of conditional code execution (as opposed to boolean evaluation) clear.
Thank god he didn't try php. echo 2 && 1; // 1 echo 1 && 2; // 1 echo 2 || 1; // 1 echo 1 || 2; // 1 echo 2 ?: 1; // 2 In php ?: is javascript's || Unfortunately there is no && that works correctly.
Came here to say this. If you use var_dump you can see it's coercing the result to a bool. $ php -r 'var_dump(1 && 2);' bool(true)
The odd bit is that casting a boolean to a string[0] with echo coerces the result to (string) "1" for true and (string) "" for false.
[0]: http://www.php.net/manual/en/language.types.string.php#langu...
Earlier quoted context omitted.
Ugh, `or` is mostly useless in PHP. That code is identical to: launchMissiles() || die('failure');
That code is the same, but or has a lower priority than ||, so they are not the same is the code before the or is an expression. Also, using or instead or || for these types of things is more readable since it makes your intent of conditional code execution (as opposed to boolean evaluation) clear.
Considering 99.9% of it's use in PHP is some variant of "connect() or die()", I stand by my statement. Besides, those "connect() or die()" expressions are widely considered bad-practice in the first place.
Earlier quoted context omitted.
You mean, like, in the compiler? If x is actually a macro that expands to zero, that will (or at least should, for a sufficiently smart compiler) happen. Otherwise, I can’t imagine a runtime check of this being appreciably faster than hardware multiply. Right?
I would guess he/she meant something along the lines of x * some_really_complicated_expression. If x is 0, you would not need to evaluate the other operand at all. It may even be a faster, but I doubt any compiler does this sort of optimization, since it is not safe in languages with non-pure functions. The complicated expression could change some global state or perform input/output. E.g. in Haskell, it would be pos…