Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>A string is an array, so <code>"hello"[ 1 ] == 'e'</code>. Furthermore an array decays to a pointer to its first element, and the subscripting operation is defined as <code>array[ index ] == * ( array + index )</code>. The addition produces a pointer after the first element.</p> <p>The expression in the <code>#define</code> is confusing because it relies on precedence rules rather than parentheses, and does this in a funny order besides. This is really not an example of good code.</p> <p>It's unnecessary to force the compiler to evaluate something at compile time. All compile-time constant expressions will be optimized as such when optimization is enabled, and otherwise you might want to step through the evaluation in the debugger! So here is a reformatted version:</p> <pre><code>if ( ( op % 8 ) &amp; // low 3 bits select conditions for execution ( s[ op / 8 ] &gt; 'Z'? // lowercase letters go through complicated mapping ( " (),-089&lt;&gt;?BCFGHJLSVWZ[^hlmnxy|}"[ s[ op / 8 ] - 'Z' - 4 ] ) + 130 : s[ op / 8 ] - " (("[ s [ op / 8 ] / 39 ] ) ) { // uppercase is simpler code; } </code></pre> <p>This is still quite obfuscated and likely inefficient. I can't tell why the author is doing things this way (didn't watch the YouTube) but since <code>op8 = op % 8</code> generates the low three bits, i.e. a number in the range 0..7, it seems pointless to do something such as add 130 before extracting a subset of the low three bits again (this time with the <code>&amp;</code> operator).</p> <p>Anyway…</p> <p>This calculates an index into the macro's argument string:</p> <pre><code>[ s[ op / 8 ] - 'Z' - 4 ] </code></pre> <p>This maps uppercase letters in the macro argument string to other letters… don't ask me why. Looks like evidence of flawed design; at this level, the string should be in a format without a need for translation.</p> <pre><code>( " (),-089&lt;&gt;?BCFGHJLSVWZ[^hlmnxy|}"[ s[ op / 8 ] - 'Z' - 4 ] ) </code></pre> <p>Finally, the number 130 is added. Since <code>130 % 8 == 2</code>, I would think 2 would also work. Beats me. Also, performing addition here has the side effect of changing the expression's type to <code>int</code>, but it doesn't matter whether 130 is inside the range of <code>char</code>.</p> <pre><code>( " (),-089&lt;&gt;?BCFGHJLSVWZ[^hlmnxy|}"[ s[ op / 8 ] - 'Z' - 4 ] ) + 130 </code></pre> <hr> <p>Putting binary data into string literals is a favorite strategy for obfuscation and "Code Golf", the sport of making a program as short as possible. It is a way to make a program unreadable and fairly compact in memory, <em>not</em> a way to make it faster, and not the best way to optimize for memory consumption either. If you want a table of numbers, specify them as numbers in hex, or decimal.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload