A ruler with the logo for the Lua Programming language

  • yetAnotherUser
    link
    fedilink
    arrow-up
    87
    ·
    10 months ago

    You forgot putting in the alt text that the ruler’s scale starts at 1 instead of starting at 0.

  • lugal@lemmy.ml
    link
    fedilink
    arrow-up
    17
    ·
    10 months ago

    Why does it go to 19 and not 20? You’re saving on the wrong end!

    • Kerb@discuss.tchncs.de
      link
      fedilink
      arrow-up
      59
      ·
      edit-2
      10 months ago

      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

      • Amaltheamannen@lemmy.ml
        link
        fedilink
        arrow-up
        20
        ·
        10 months ago

        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].

        • SkyeStarfall@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          9
          ·
          10 months ago

          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.

  • ezchili@iusearchlinux.fyi
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    10 months ago

    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]

    • barsoap@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      10 months ago
      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
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        10 months ago

        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
          link
          fedilink
          arrow-up
          1
          ·
          10 months ago

          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
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            10 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