4 ms·

It's not that convenient an untruth seeing as these are probably some of the first things you learn in C, and some of the first gotchas that'll getcha. Having

• bluetomcat 10y ago
  Some of the first things that people learn in C is the fallacy that "arrays and pointers are equivalent". An array is a series of contiguously laid-out objects that has a size known at compile time (except C99 VLAs). A pointer, on the other hand is merely a "single cell" that is supposed to contain an address and can be added/subtracted to, also dereferenced. The truth is that array names decay to pointers except when the array is an operand to the `sizeof` or `&` operator.
  • jandrese 10y ago
    Right, the fact that arrays aren't pointers is academic when they decay to pointers at the drop of a hat. In fact it's so easy to decay the array to a pointer that it is generally best to always treat it as a pointer lest you get burned later on during a code refactor. This mostly means never using sizeof() to get the size of an array.
    • bluetomcat 10y ago
      Even if we simplify it this way, arrays are still different because they cannot be assigned to and their decayed pointer can never be NULL (they always have a backing storage provided by the compiler): int arr[5]; int *ptr; // "arr" has a fixed backing storage of sizeof(int) * 5 bytes // "ptr" may point to anything or be NULL, depending on control flow
      • jandrese 10y ago
        Best to check for NULL anyway though, because anything can happen once you let it decay to a pointer. Never assigning them is a good idea though, maybe it's best to think of them as constant pointers? But that's more confusing terminology for a C programmer, so maybe not. People get really wrapped around the axle when differentiating a constant pointer from a pointer to a constant.
• baydonFlyer 10y ago
  I wish that was the case, as in the "first things you learn in C" unfortunately in most cases I come across it's not and many C programmers maybe know that very basics (int* ptr = arr;) but not much beyond that.
• grymoire1 10y ago
  I think it's more likely the reaction to someone who uses magic languages that perform complicated actions over a simple assignment. If you think of C as a high-level assembly language whose assignment instruction is converted into a single machine instruction, this type of behavior is not so surprising.
  • kbp 10y ago
    > I think it's more likely the reaction to someone who uses magic languages that perform complicated actions over a simple assignment. If you think of C as a high-level assembly language whose assignment instruction is converted into a single machine instruction, this type of behavior is not so surprising. C assignment isn't that simple. Consider this program: #include <stdio.h> struct point { int x; int y; }; int main(void) { struct point p1 = { 0, 0 }; struct point p2 = p1; ++p2.x; printf("(%d, %d), (%d, %d)\n", p1.x, p1.y, p2.x, p2.y); } It prints "(0, 0), (1, 0)", as most people would expect. C isn't as transparent a layer over assembler as some people like to imagine; it just doesn't have first class arrays.
    • TillE 10y ago
      That's just doing a copy of contiguous memory though? Sure, C has simple custom data types. I like to think of it as one small step above assembly languages; it's certainly not a "portable assembly", but it's about as low as a high-level language can possibly be.
      • kbp 10y ago
        Yes, C is definitely a low-level language, I was just responding to someone's inaccurate justification for why you can't copy arrays like that.