A convenient untruth: Array notation in C is a lie

Post by Vogtinator » Thu, Dec 22, 2016, 7:39 PM UTC

pasquinelli wrote: post #75

SomeStupidPoint wrote: post #43

Earlier quoted context omitted.

I mean, int[5] and int[7] would be different types, and lots of bugs happen from passing something besides the appropriate array type to a function. That being said, most languages which disambiguate between int[5] and int[7] provide some kind of polymorphism (and usually store it as a struct of size + data, to enable that). For example: you can define a first function that goes from t[N]->t pretty easily, and it wou…

Right, in a language with dependent types there is a type-level difference between int[5] and int[7], but c is not such a language, therefore using a syntax that encourages the mistaken notion that there is a type-level difference between int[5] and int[7] would be misleading.

Post by bluetomcat » Thu, Dec 22, 2016, 7:43 PM UTC

jandrese wrote: post #119

bluetomcat wrote: post #10

Earlier quoted context omitted.

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 whe…

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.

    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

Post by gpderetta » Thu, Dec 22, 2016, 7:49 PM UTC

mojuba wrote: post #48

rossy wrote: post #39

This gets weird when you compare it to how structs work in C. Both are complex data types, so I sometimes forget that array semantics are totally different to struct/union semantics. Unlike arrays, in ANSI C, structs are real value types. You can pass them by-value to functions, return them by-value from functions and assign them by-value to variables of the same type. Also, structs never work like pointers to themse…

Worth noting that you can always wrap an array in a structure and kick it around in your program happily, as if it's how the language should've been. struct { int a[5]; } arr5 = {{4, 3, 2}}; What's a bit weird though, is that while initialization like above is possible, assignment of a contsant is not as smooth in C, you will have to typedef your structure and use it in a typecast expression: typedef struct { int a[5…

Post by Animats » Thu, Dec 22, 2016, 7:54 PM UTC

chrisseaton wrote: post #120

Animats wrote: post #118

I once proposed a backwards-compatible way out of this: "Safe Arrays for C"[1]. The fundamental problem with arrays in C is that compiler has no idea how big they are. My proposal was to replace int read(int fd, char buf[n], size_t n); with a safe form int read(int n; int fd, char (&buf)[n], size_t n); This says that the size of "buf" is "n", which comes in as another parameter. There are no array descriptors; the ge…

> The fundamental problem with arrays in C is that compiler has no idea how big they are Isn't that the compiler's choice, to not know how big they are? You could write a standards compliant implementation of C that did track how big arrays were if you wanted to couldn't you?

Post by MaulingMonkey » Thu, Dec 22, 2016, 8:32 PM UTC

  int (&r)[5] = array;

  std::copy(a+0, a+N, b+0);