Hacker News Reader

Comment by saagarjha | Hacker News Reader

Is it bad that I've written some of these in my normal code? In particular, I use the concepts in these when they're relevant:

  *(c ? &x : &y) = v;

  return (char *[]){"No", "Yes"}[!!x];

(Note: for the second one, I use the "selecting from a temporary array" and !! separately; if I only had two options then I'd use x ? "Yes" : "No" of course.)

View on HN

I don't find those obfuscatory at all either, and instantly understood them upon first reading. I think they are a form of "data-oriented" style of programming, where array indexing and selection via ?: are preferred over "code-oriented" control flow statements. In my experience, the former actually tends to create more concise and maintainable code, since it often means a lot of the logic becomes table-driven and easily modified. The latter tends to result in very long and "branchy" code with lots of if/else statements that ultimately contain tiny bodies that don't do much.

Combining multiple booleans into an integer and using that as a switch or index is another related technique.

To modify an old saying slightly, perhaps "one person's obfuscation is another person's simplicity and elegance."

> I don't find those obfuscatory at all either, and instantly understood them upon first reading

I understood the whole list of these obfuscation tricks upon first reading but its still obfuscation.

Creating an array instead of an if-else-switch like the second line is fine but for just two elements and in combination with !!x (and !!x in general) its just nonsense and doesn't help at all.

I'm all for code-density and avoiding repetition so I too use ?: whenever I can but not on the left side of an assignment. That's just an obfuscated if-else-statement. If normal code results in very long and "branchy" code you can rearrange your code in a better way.

FWIW, !! is a fairly idiomatic way to cast a value to bool.

Ints are automatically converted to bool, there is no need to cast. What this does is it restricts the int to 1 or 0. The clean way to write this is x ? 1 : 0. This is understandable even if you don't know the Boolean inversion of 0 is 1 (Which isn't self-evident. For example in Basic its -1).

They are converted to bool in bool context. Outside of that you have to force it.

   int countNonZero = 0;
   for (int i = 0; i < values.size(); ++i) {
       countNonZero += !!values[i];
   }

Also c++ has explicit operator bool();

edit: not a great example as values[1] >0 would be better.

You don't have to enforce a conversion from int to bool if you just want a bool. In this example you don't want to increment by 'bool', you want to increment by 1 or 0 (which are ints). So you use !!x to convert to bool and back to int.

The reason I'm pointing this out is that often enough I had to work with code where this distinction was unknown to the author and you come across code like if (!!x) which is, again, just nonsense.

edit: not a great example as values[1] >0 would be better.

Only if that's an array of unsigned ints, as otherwise the code would count only positive nonzeros.

You can also typecast to bool since C99. (bool)x if you include <stdbool.h> or (_Bool) if not.

I try to write C/C++ so that the state and flow of control is fairly obvious in a debugger. Complicated and "electric" statements like the ones above are succinct and maybe even obvious, but they're difficult to step through, and they don't really offer any advantage in code quality.

Screen space is cheap. Say what you mean. Clever today is usually a headache tomorrow.

I can fit over 500 lines of code on my screen but I still prefer dense code. There's just something nice about not needing to jump around so much (whether with the eyes or the cursor or file), and being able to see more of the forest at once.

> Is it bad that I've written some of these in my normal code?

yes

Well, that depends on context. Always insure your code is good in the context it appears.

    yourCode = bad;

    temp = bad;
    bad = good;
    good = temp;

    conclusion = (yourCode == bad)

As we can see from evaluating this code, in this context, it isn’t bad.

In general, if something is bad you can change that thing or change the context. Your job, your living arrangements, etc. People often are slow to change the context, even when a small change can make all the difference.

You might want to create an include file if you have a lot of code to check.

mycodeisalwaysgood.h seems self-explanatory.

I wonder if even replying is encouraging this behavior.

I can understand the code and if all you function does is this 2 statements I guess it is ok. Myself however I would not write any code of meaningful size in this style.

I switch between many languages often enough so anything even remotely esoteric gets forgotten instantly and causes my brain to pause at suspicious line and making me think too much about the trees instead of the forest.

If however I was only using C and nothing else maybe I'd be catching this bug myself, one never knows ;)

>*(c ? &x : &y) = v;

Do you know why need to use pointer magic here?

Tried (c ? x : y) = v; and wondering why that doesn't work.

because ternary operation is a Rvalue only in C. In C++ and as gcc extension it can be used as Lvalue, but not in regular plain C.

>return (char *[]){"No", "Yes"}[!!x];

Is !!x equivalent to x here?

No, it "collapses" an integer to 0 or 1. (Essentially, it's x != 0.)

Personally I prefer (x ? 1 : 0) over (x != 0) or !!x for this sort of thing.

It fits semantically with "I'm using x as a boolean, but it may not be 1".

i'm on the fence about this... i don't love type coercions, but (!!x) is nice because you don't have to stop and check - was it (x ? 1 : 0) or (x ? 0 : 1), (x !=0) or (x==0)? i think arthur whitney said something in the vein of "less characters - less room for typos" :)

!!x is idiomatic. (bool) cast is modern.

I use !=0 in only one context, if(strcmp(a,b) != 0) to check if two strings differ. Normally if an if() expression I don't check explicitly for 0 or not 0, except for strcmp class of functions, because of the ordered comparison of it (<0, 0, >0) , its "boolean" value is inverted, so somewhat counter intuitive if used with implicit boolean values.

I don't think !! can be too common an idiom when the one time I recall using it in a corporate setting it was pointed out as absurd. And I agree it's not explicit and clear. But this seems a matter of style.

Cast to bool has me extremely nervous because ... It works in C99's _Bool type, but I have lots of bad memories of security bugs when using this approach with pre-standard custom bool types, which are still in common use including but not limited to Win32 and COM, or Objective-C.

The bug I am thinking of looks like this:

    long long ll = 1LL << 32;
    bool b = ll;

    puts(b ? "yes" : "no");

I just tested to confirm. This prints "yes" when using C99 stdbool, presumably because they standardized it to work. If you change bool to a common choice for pre-standard bool typedefs (int or char, say), it prints "no" because the large nonzero value doesn't fit in that type. "Just use the standard type" you might say. But if we were working somewhere that required legacy nonstandard bools that is not our choice, and further, a later refactor on may start using those other types some day even if we make the correct choice today. So there is an argument to be consistent about avoiding this type of bug.

If x is any nonzero value [example: 2], !!x is 1.

Any nonzero expression is true, and 0 is false. But the result of !, or ==, ||, or any of those other boolean operators is 1 for true.

Recall relatedly that C didn't have a bool type until the 1999 standard, which introduced <stdbool.h>. C++ had it earlier, but for a long time the C way to store a boolean expression into a variable might have been int, or some nonstandard typedef. This is why so many libraries and frameworks in the C world define their own boolean type.

Reply on news.ycombinator.com