A convenient untruth: Array notation in C is a lie

Post by yason » Thu, Dec 22, 2016, 10:50 PM UTC

Post by ssalazar » Thu, Dec 22, 2016, 11:36 PM UTC

unscaled wrote: post #137

bluecalm wrote: post #37

Earlier quoted context omitted.

I don't agree with: int[5] arr; being a more readable syntax. The problem is that if you later have: int[7] arr2; It would make sense that arr and arr2 are different types (as the thing on the left is different) while they are the same type and you should be able (hopefully!) to use them as arguments to the same function. On the other hand I agree that: int* arr; makes more sense than more commonly used: int *arr; al…

Well, had C been really strongly-typed then the hypothetical 'int[5]' and 'int[7]' would have been different types, and 'int[]' would be the size-agnostic type for an array. Then you could easily get creature comforts such as: typedef uint8_t[16] guid_t; typedef uint8_t[20] sha1_digest_t; These typedefs would then have copy assignment, pass-by-value semantics and everything else you'd expect from value types.

    > typedef uint8_t[16] guid_t;
    > typedef uint8_t[20] sha1_digest_t;

Post by clarry » Fri, Dec 23, 2016, 12:31 AM UTC

ThatGeoGuy wrote: post #96

utopcell wrote: post #52

C now has static array indices. For example void func(int arr[static 8]) {} imposes a limit on the size of the array that can be passed as an argument (you cannot pass an array of 7 or fewer elements.) I'd suggest that to the author, but given the article, I fear it may give him a heart attack.

I know they're called static array indices, and they're called that because of the use of the keyword `static`, but they don't have to be compile time constant at all (and checks aren't performed at compile time, IIRC). You can have the following: void foo(size_t len, int arr[static len]); Which is really useful in asserting that you won't pass in the null pointer at runtime (so you can remove any `if (arr) {}` check…

Post by flukus » Fri, Dec 23, 2016, 12:44 AM UTC

SomeStupidPoint wrote: post #43

bluecalm wrote: post #37

Earlier quoted context omitted.

I don't agree with: int[5] arr; being a more readable syntax. The problem is that if you later have: int[7] arr2; It would make sense that arr and arr2 are different types (as the thing on the left is different) while they are the same type and you should be able (hopefully!) to use them as arguments to the same function. On the other hand I agree that: int* arr; makes more sense than more commonly used: int *arr; al…

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…

Post by kibwen » Fri, Dec 23, 2016, 1:13 AM 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.

  // error: expected an array with a fixed size of 5 
  // elements, found one with 7 elements
  let x: [i32; 5] = [1,2,3,4,5,6,7];