51–59 of 59 posts
C is parsed boustrophedonically.
[1] This is apparently the ancient Greek origin of the word.
> "str is an array 10 of pointers to char" Wow, imagine if it was possible to actually use a language like that do declare the type of the variable like that? Something like str: array [0..9] of ^Char; or even var str [10]*uint8 Just imagine...
var str: array[10, ptr char]> "str is an array 10 of pointers to char" Wow, imagine if it was possible to actually use a language like that do declare the type of the variable like that? Something like str: array [0..9] of ^Char; or even var str [10]*uint8 Just imagine...
Or even var str: array[10, ptr char]
I've written some C code recently, and it came to me perhaps the pointer syntax may not be ideal. I'm not sure what the ideal would be, but I think a different notation for usage and declaration could make it less confusion. In particular I associate '*' (used as *ptr, i.e. content that ptr points to), with content, as opposed to '&' (from &var, address of var), so again '*' means content thing points to. But in decl…
I thought it was a bit of a miss that C didn't use ^ as the pointer sigil. I mean it's literally pointing. I'm guessing some early terminals didn't have that character on the keyboard.
Earlier quoted context omitted.
No, I think he means that for any given type, you can wrap it in an array the same way. Your example is demobstating that it even works recursively, but it works in the simple case too by wrapping "int" in an array to get an array of ints. There's no need to jump back and forth between each side when adding new layers (which gets described as a "spiral", but in a single line of code, I'd argue that it's really just j…
If I would add another array, it would look like: int c_style_array[2][5][3]; There is also no jumping back and forth. C declarations are also recursively constructed. One can complain about the irregularity of pointers syntax.
Earlier quoted context omitted.
The "existing type" in your example is int, the "extra layer" is the array type that "wraps" it
I guess? That's pretty confusing wording, and a bizarre rant if so.
Earlier quoted context omitted.
Or even var str: array[10, ptr char]
Eh, or that, I guess. I personally would rather not squish the type of the elements together with the dimensions, but it can work like that, sure. Especially if you use square brackets for generic instantiation, so your example is semantically close to std::array of C++. But if the language uses the square brackets (almost) exclusively for array indexing, then having simply "[10]" prefix as a shorthand for "array of…
Yes, it is like that.
Earlier quoted context omitted.
i find Zig does it fairly well. there is also no ambiguity between pointer and multiply.
Yeah, they took it from Pascal: var p: ^integer, i: integer; p := @i; p^ := 42; Which follows an obvious "if modifier of a base type goes to the left of the type, then the operator that uses this modifier goes to the right in the expression". Just like "array of T/[]T" translates into "arr[index]".