6 ms·

No, it is strange, because C decides to dereference according to the datatype of "a" in both cases, and not according to how the user syntactically declares wha

No, it is strange, because C decides to dereference according to the datatype of "a" in both cases, and not according to how the user syntactically declares what is to be understood as array and index. In other words, if a is char[]/char* and index is int, C does *((char*)a + (int)index) and *((int)index + (char*)a) and not as one could expect *((char*)a + (int)index) and *((int*)index + (char)a) for a[index] and index[a] respectively.

simias 7y ago
I always understood it as some kind of compiler-level macro, where a[b] is expanded into <star>(a + b) and then normal arithmetic rules take over, in which case there's no strangeness as far as I can tell (i.e. it doesn't matter which of a or b is the pointer and which is the integer because C defines both "int + ptr" and "ptr + int" as doing the same thing). But frankly it's a bad choice if we're talking about C's "esoteric quirks" because both this and Duff's Device are things that you effectively never encounter in the wild (it's the "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" of the C language, they're interesting to know about but not of much practical use). There are much better "features" of C to single out, for instance the two million different meanings for the "static" keyword, the fact that arrays declared as function parameters do not behave like arrays but like pointers (hey, you can put "static" in there too now! But it still doesn't make it work like a proper array), the many surprising undefined behaviors regarding integer overflow, aliasing rules etc...
gpderetta 7y ago
Adding a pointer and an index yield a pointer no matter which side the pointer is, i.e operator+ is commutative. It would be extremely surprising if switching sides of the sum would implicitly convert an index to a pointer. You could argue that operator[] should not allow a non pointer on the LHS, and you would probably right, but as it stands now, it is just syntactic sugar for operator+ and just dereferencing the while expression.
- chii 7y ago
  understanding pointer dereferencing and its meaning is no different than understanding lazy evaluation and strict evaluation in terms of difficulty. I would argue that lazy and strict is easier a concept to understand. The reason a lot of people think that haskell's lazy/strict behaviour is quirky is only because they are not familiar with functional programming concepts. Nobody bats an eye when an article talks about cache lines and how you organize data in a multi-dimensional array (zig-zagging one way is faster than the alternative). But this info is just as difficult to have learnt, 'cept that as a seasoned C programmer, you would've likely to have encountered this already.
  - gpderetta 7y ago
    > Nobody bats an eye when an article talks about cache lines and how you organize data in a multi-dimensional array the vast majority of programmers won't have any idea about any of that. Arguably (not by me BTW) they don't need. edit: also, caches are a necessity of modern (and not so modern) computer architectures, every program has to deal with them. Laziness is sort of a self inflicted weakness of Haskell. edit2: I can't write any Haskell, but I can read a bit of it (like python, it makes for excellent pseudocode I think). Sometimes I fail to understand how some algo could possibly work, but then 'ah, right, laziness'. I'm sure it comes natural after a while, but it is definitely a barrier.
  - coldtea 7y ago
    >understanding pointer dereferencing and its meaning is no different than understanding lazy evaluation and strict evaluation in terms of difficulty. I would argue that lazy and strict is easier a concept to understand. Not even close. Pointer and dereference are something we do all the time in the real world (e.g. a pointer is like the semantic between word and thing) and can have easy to understand examples (the classic storage box with holds a value, and the pointer being the number of the box, etc). Still tons of programmers can't get their head around them... Lazy/strict is far more challenging, and whereas pointers have no mystery after understanding the basic mechanism, telling how a lazy program behaves and spends memory etc is nigh impossible above a certain complexity -- heck, this is a common lament of seasoned Haskell programmers. >Nobody bats an eye when an article talks about cache lines and how you organize data in a multi-dimensional array (zig-zagging one way is faster than the alternative). Many bat an eye. Heck, many not even get pointers, much less cache lines, and optimal access/sharing patterns...

simias 7y ago

I always understood it as some kind of compiler-level macro, where a[b] is expanded into <star>(a + b) and then normal arithmetic rules take over, in which case there's no strangeness as far as I can tell (i.e. it doesn't matter which of a or b is the pointer and which is the integer because C defines both "int + ptr" and "ptr + int" as doing the same thing). But frankly it's a bad choice if we're talking about C's "esoteric quirks" because both this and Duff's Device are things that you effectively never encounter in the wild (it's the "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" of the C language, they're interesting to know about but not of much practical use). There are much better "features" of C to single out, for instance the two million different meanings for the "static" keyword, the fact that arrays declared as function parameters do not behave like arrays but like pointers (hey, you can put "static" in there too now! But it still doesn't make it work like a proper array), the many surprising undefined behaviors regarding integer overflow, aliasing rules etc...

gpderetta 7y ago

Adding a pointer and an index yield a pointer no matter which side the pointer is, i.e operator+ is commutative. It would be extremely surprising if switching sides of the sum would implicitly convert an index to a pointer. You could argue that operator[] should not allow a non pointer on the LHS, and you would probably right, but as it stands now, it is just syntactic sugar for operator+ and just dereferencing the while expression.

chii 7y ago
understanding pointer dereferencing and its meaning is no different than understanding lazy evaluation and strict evaluation in terms of difficulty. I would argue that lazy and strict is easier a concept to understand. The reason a lot of people think that haskell's lazy/strict behaviour is quirky is only because they are not familiar with functional programming concepts. Nobody bats an eye when an article talks about cache lines and how you organize data in a multi-dimensional array (zig-zagging one way is faster than the alternative). But this info is just as difficult to have learnt, 'cept that as a seasoned C programmer, you would've likely to have encountered this already.
- gpderetta 7y ago
  > Nobody bats an eye when an article talks about cache lines and how you organize data in a multi-dimensional array the vast majority of programmers won't have any idea about any of that. Arguably (not by me BTW) they don't need. edit: also, caches are a necessity of modern (and not so modern) computer architectures, every program has to deal with them. Laziness is sort of a self inflicted weakness of Haskell. edit2: I can't write any Haskell, but I can read a bit of it (like python, it makes for excellent pseudocode I think). Sometimes I fail to understand how some algo could possibly work, but then 'ah, right, laziness'. I'm sure it comes natural after a while, but it is definitely a barrier.
- coldtea 7y ago
  >understanding pointer dereferencing and its meaning is no different than understanding lazy evaluation and strict evaluation in terms of difficulty. I would argue that lazy and strict is easier a concept to understand. Not even close. Pointer and dereference are something we do all the time in the real world (e.g. a pointer is like the semantic between word and thing) and can have easy to understand examples (the classic storage box with holds a value, and the pointer being the number of the box, etc). Still tons of programmers can't get their head around them... Lazy/strict is far more challenging, and whereas pointers have no mystery after understanding the basic mechanism, telling how a lazy program behaves and spends memory etc is nigh impossible above a certain complexity -- heck, this is a common lament of seasoned Haskell programmers. >Nobody bats an eye when an article talks about cache lines and how you organize data in a multi-dimensional array (zig-zagging one way is faster than the alternative). Many bat an eye. Heck, many not even get pointers, much less cache lines, and optimal access/sharing patterns...