For the rest of us who are manipulating sets of values and not offsets on pointers and aren't delusionally attached to conventions, there's arr[1] to arr[n]

[–] navigatron@beehaw.org 2 points 8 months ago

But then arr.length == the last index, and that’s just too convenient :(

[–] barsoap@lemm.ee 2 points 8 months ago* (last edited 8 months ago) (1 children)

ptr[n] == n[ptr] == *(ptr+n) == *(n+ptr).

Addition is commutative so of course array indexing is and why the hell are you taking the address of a pointer. Also it's not "int pointer foo" but "foo, dereferenced, is an int" that's why it's int *foo not int* foo. I won't die on that mountain fortress because it is unassailable. Never write char **argv (but char *argv[]) but it's vital to understand why it doesn't make a difference to the compiler. It's what passes as self-documenting code in C land.

Also 0-based indexing is older than C. It's older than assembly.

[–] ezchili@iusearchlinux.fyi 1 points 8 months ago* (last edited 8 months ago) (1 children)

Why do you assume it was a pointer type? There's no types. Why do you assume C either? This is pseudo code to illustrate pointer offsets

[–] barsoap@lemm.ee 1 points 8 months ago (1 children)

Why do you assume it was a pointer type?

Because afterwards you said arr[n]. By convention n is definitely an integer and if arr is also, say, an integer, you get

 error: subscripted value is neither array nor pointer nor vector

Why do you assume C either?

Because you didn't write ^(@arr+0) (Not sure that's even valid though my Pascal is very rusty).

This is pseudo code to illustrate pointer offsets

Granted. But then it's still Pseudo-C, not Pseudo-Pascal or Pseudo-Whitespace.

[–] ezchili@iusearchlinux.fyi 1 points 8 months ago* (last edited 8 months ago)

It's pseudo-nothing

It conveys a point, which you got, and if you decide to invent a syntax and bicker on it it's just you

Really pointless discussion