top | item 2871404

a[5] == 5[a]

21 points| stephth | 14 years ago |stackoverflow.com | reply

36 comments

order
[+] mkelly|14 years ago|reply
Warning: crazy rant coming.

So this is what HN has degenerated to? I'm sorry, but I remember eagerly reading the front page, learning things from interesting articles, and -- more importantly -- reading well-written commentary from people far more accomplished than I. I lurked, because I couldn't contribute at the level that most of the regular commentors could, but I learned a great deal.

HN has retained its preoccupation with not being reddit (which is noble), but has not retained the quality to justify it.

Great communities are transient, and HN is probably what taught me that. I have nothing but respect for pg, and for the community that once populated HN.

Peace. I'm out.

Crazy rant done.

[+] lunaru|14 years ago|reply
To be honest, I feel the same way, but maybe there's a good explanation for the relative decline of "quality".

I think I started lurking HN back in 2007 (which I also believe is the first year of HN). I remember feeling a euphoric sense of being overwhelmed with great content from knowledgeable people and articles. I learned a lot about start ups. I learned a lot about programming. I learned a lot about partaking and consuming thoughtful commentary in a semi-anonymous setting.

But you know what? All of that content is still here, in different formats. The audience is bigger and so there tends to be more mainstream stuff on HN now, particularly around politics. But I think the biggest change is in myself. I've read the same stuff about lean startups at least 100 times now rehashed in different ways. Even though I've never raised money from a VC before, every time I read something on HN about it, I feel like I've been through the process dozens of times. Every 37signals blog post that gets submitted seems like a rehash of the last one. So most of the submitted content around those topics seem like old-hat.

At some point, when you continue to consume the content from the same sources for years on end, you're going to see more repeat episodes and you'll have fewer stimulating moments. That's just the nature of it - and I think it's just as important to recognize that we're transient individuals. Your probably a different person now with a higher capacity and understanding and that's probably in part thanks to HN.

[+] 5hoom|14 years ago|reply
Your finding the articles less interesting could be a function of you becoming more knowledgable yourself, therefore there is less "low hanging fruit" with regards to new knowledge for you to acquire.

Might be a sign that it's time for you to start posting some well-writen commentary yourself ;)

[+] pyre|14 years ago|reply
I think that it's general knowledge that a[x] is a + (x * sizeof a). The idea that a[x] could be reversed to x[a] is probably not common knowledge though. I don't necessarily think that a[x] = x[a] would be "C 101." I've certainly never come across any C code that uses this property and I can't really think think of any good uses for this property that don't end up ruining the readability of the code. And in general, it seems a rather useless property that, as others have stated, is just a side-effect.

I could just as easily claim that HN has 'degenerated' if someone posts a Stack Overflow post about what the /o flag does on Perl regexes. Or maybe there will be a Stack Overflow post about how substr('abc', 1, 1) == substr('abc', 0, 1) in Oracle because it helpfully translates the 0 index to a 1 index. I mean, it's right here in the Oracle docs[1]:

  When position is 0 (zero), then it is treated as 1.
It's Oracle 101!

[1] http://download.oracle.com/docs/cd/B28359_01/olap.111/b28126...

[+] biot|14 years ago|reply
Trying to intuit how a language works tends to be problematic. To understand this operation, you need to look it up in the spec: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Section 6.5.2.1 "Array Subscripting" states in item (2) under "Semantics" on page 70:

  A postfix expression followed by an expression in square brackets []
  is a subscripted designation of an element of an array object. The
  definition of the subscript operator [] is that E1[E2] is identical
  to (*((E1)+(E2))). Because of the conversion rules that apply to
  the binary + operator, if E1 is an array object (equivalently, a
  pointer to the initial element of an array object) and E2 is an
  integer, E1[E2] designates the E2-th element of E1 (counting from
  zero).
In other words:

  a[5] is equal to (*((a)+(5)))
  5[a] is equal to (*((5)+(a)))
So what are the rules for E1+E2? Refer to section 6.5.6 "Additive Operators", item (8) under "Semantics" on page 83:

  When an expression that has integer type is added to or subtracted
  from a pointer, the result has the type of the pointer operand. If
  the pointer operand points to an element of an array object, and
  the array is large enough, the result points to an element offset
  from the original element such that the difference of the subscripts
  of the resulting and original array elements equals the integer
  expression. In other words, if the expression P points to the i-th
  element of an array object, the expressions (P)+N (equivalently, 
  N+(P)) and (P)-N (where N has the value n) point to, respectively,
  the i+n-th and i−n-th elements of the array object, provided they
  exist.
In other words, if (P)+N is equal to N+(P), you need only substitute "a" for "P" and "5" for "N" and that proves a[5] == 5[a]. If I've missed something, corrections are welcomed.
[+] Someone|14 years ago|reply
Given that these are separate sections in the C spec, would

  &12[5] == 17
(ignoring OS memory protection)?
[+] guyzero|14 years ago|reply
I suppose this is an evergreen topic for new C programmers. I find it surprising that HN is posting something that's basically a verbatim quote from K&R which was first published in 1978. a 33 year-old C hack ain't news.

Than again, I guess the days where you could assume everyone who knew how to program programmed in C are long gone.

[+] pyre|14 years ago|reply
You're also assuming that everyone that knows how to program in C has read K&R. That's like assuming that everyone that knows how to program has read the Art of Computer Programming.
[+] Natsu|14 years ago|reply
It would be familiar to anyone who has read IOCCC submissions or K&R, I should think.

But it's quite surprising for just about everyone else, I think. Does any other language allow this? I think JavaScript allows some syntactic contortions, but I don't remember offhand if it permits this particular one.

[+] mkelly|14 years ago|reply
I agree. I posted a crazy rant elsewhere in the comments, actually, prompted by the same thoughts.

Poor HN.

[+] pyre|14 years ago|reply
That explanation only partially works.

  a[5]
evaluates to something like:

  *(a + (sizeof(a) * 5))
so shouldn't

  5[a]
evaluate to

  *(5 + (sizeof(5) * a))
Those don't seem equivalent, unless I'm missing something.
[+] lurker19|14 years ago|reply
As noted in the SO comments: when compiling the "+", the compiler uses the sizeof of the referenced type of whichever addend is actually a pointer.
[+] jackowayed|14 years ago|reply
It works if you think of it as expanding to *(a + 5). Pointer addition is defined to be scaled by the size of the pointer.
[+] barrkel|14 years ago|reply
No; a[5] evaluates to (a + 5), and 5[a] as (5 + a).

Separately:

    e + p where e : integer-type and p : pointer-type
    p + e where e : integer-type and p : pointer-type
are evaluated roughly as:

    (pointer-type)(e*sizeof(*p) + (size_t)p)
    (pointer-type)((size_t)p + e*sizeof(*p))
but these are very rough translations, because we're wandering into implementation-defined territory (substitute uintptr_t for size_t as desired etc).

The type analysis on the addition is reminiscent of e.g. promoting integers to floats:

    i + f where i : integer-type and f : float-type
    f + i where i : integer-type and f : float-type
correspondingly:

    (float-type)i float-type::+ f
    f float-type::+ (float-type)i
The '+' built-in is overloaded in C.
[+] unknown|14 years ago|reply

[deleted]

[+] tzs|14 years ago|reply
It's more amusing for multi-dimensional arrays:

   a[x][y] = y[x[a]]
   a[x][y][z] = z[y[x[a]]]
and so on.
[+] kqueue|14 years ago|reply
C 101.. HN is becoming sillier every day.
[+] bnegreve|14 years ago|reply
Ok, the "interesting" thing is this expression is that 5 is accepted as a variable identifier although it does not meet the requirements to be one. The fact that the expression evaluate to a result that turns to be correct is not so relevant.
[+] lurker19|14 years ago|reply
I think you mean "pointer type", not "variable". 0xblah could very well a be valid pointer value.

Anyway, Array subscripting (brackets) is not an operator in C. It is just syntactic sugar. This is different from C++ (but even in C++, C compatibility is maintained for primitives) .

[+] jc-denton|14 years ago|reply
Old! C programmers know how this is expanded.