A ruler with the logo for the Lua Programming language
You forgot putting in the alt text that the ruler's scale starts at 1 instead of starting at 0.
I honestly didn't notice.
Why does it go to 19 and not 20? You're saving on the wrong end!
thats probably taking the piss with how lua handles array indexing.
in most programming languages,
the first element of an array is element 0,
in lua arrays start with element 1.
imo it kinda makes sense,
but it causes confusion because it goes against established conventions
The reason for the convention is that it used to be just a pointer (adress) to consecutive elements in memory. A[x] is then literally translated to the adress of A + sizeof(x)*x. Meaning that the first element is at A[0].
I mean, it's still the case under the hood, and languages like C do work that way. Sure, it's abstracted away in most programming languages these days, but if you ever need to do direct memory management, it's very much still how it works.
Scratch and Mathematica also have arrays start at one.
I never worked with lua but I get it now. Thanks!
this is the ruler for guys who say they have a 12" dick
BRAZIL MENTIONED!
There's a syntax for indexing starting from 0, it's
*(&arr+0) to *(&arr+(n-1))
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]
But then arr.length == the last index, and that’s just too convenient :(
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.
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
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.
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
You forgot putting in the alt text that the ruler's scale starts at 1 instead of starting at 0.
I honestly didn't notice.
Why does it go to 19 and not 20? You're saving on the wrong end!
thats probably taking the piss with how lua handles array indexing.
in most programming languages,
the first element of an array is element 0,
in lua arrays start with element 1.
imo it kinda makes sense,
but it causes confusion because it goes against established conventions
The reason for the convention is that it used to be just a pointer (adress) to consecutive elements in memory. A[x] is then literally translated to the adress of A + sizeof(x)*x. Meaning that the first element is at A[0].
I mean, it's still the case under the hood, and languages like C do work that way. Sure, it's abstracted away in most programming languages these days, but if you ever need to do direct memory management, it's very much still how it works.
Scratch and Mathematica also have arrays start at one.
I never worked with lua but I get it now. Thanks!
this is the ruler for guys who say they have a 12" dick
BRAZIL MENTIONED!
There's a syntax for indexing starting from 0, it's
*(&arr+0) to *(&arr+(n-1))
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]
But then arr.length == the last index, and that’s just too convenient :(
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 *foonotint* foo. I won't die on that mountain fortress because it is unassailable. Never writechar **argv(butchar *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.
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
Because afterwards you said
arr[n]. By conventionnis definitely an integer and if arr is also, say, an integer, you getBecause you didn't write
^(@arr+0)(Not sure that's even valid though my Pascal is very rusty).Granted. But then it's still Pseudo-C, not Pseudo-Pascal or Pseudo-Whitespace.
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