• tobogganablaze@lemmus.org
    link
    fedilink
    English
    arrow-up
    37
    ·
    3 months ago

    If I had a penny for every pixel … I’d have around $1088. Which I would take, but really it’s not enough.

  • SpaceNoodle@lemmy.world
    link
    fedilink
    arrow-up
    33
    ·
    3 months ago

    I don’t think I’ve ever explicitly gone four deep. Two is common enough, and three happens on some rare occasions, but four seems like sheer madness.

    • Ephera@lemmy.ml
      link
      fedilink
      arrow-up
      11
      ·
      3 months ago

      Dumb question, but when would you need two deep? Is it when you store a pointer as a field in a struct?

      If so, isn’t that a massive footgun, because the pointer might go invalid at any point? 🫠

      • SpaceNoodle@lemmy.world
        link
        fedilink
        arrow-up
        20
        ·
        3 months ago

        Pointers to arrays or arrays of pointers are common examples.

        Your pointers won’t just magically become invalid. You gotta fuck 'em up first.

        • Ephera@lemmy.ml
          link
          fedilink
          arrow-up
          4
          ·
          3 months ago

          Ah, you mean “pointers to arrays”, because arrays are themselves just pointers in C/C++. That one still feels like it shouldn’t be needed in practice, because you already got a pointer, why can’t you use that directly? But yeah, I have no practical experience with C/C++.

          And you do gotta fuck 'em up, as in free what they’re pointing to before you free the struct/array containing the pointers.
          But when you do stick them into a struct/array, that often means you want to move them out of the scope with the malloc and potentially store them, too.
          At that point, surely, it becomes rather difficult for your whole team to know or track down when it’s legal to free that.

          I only know from Rust that if you want to store a pointer/reference in a struct, it makes you specify the lifetime of that struct, which has to be greater or equal to the lifetime of the thing the pointer is pointing to. Hairy stuff. We’ve basically told the Rust newbies on our team to just not store pointers in structs and that’s working rather alright.

          • SpaceNoodle@lemmy.world
            link
            fedilink
            arrow-up
            4
            ·
            3 months ago

            Arrays may be implemented as pointers on C, but the distinction is on how they are used, which is why I used the verbiage I did.

            What if you need to modify a reference to a pointer, e.g. change the value of a value referencing a certain place in an array? strtol(), for example, uses a pointer to a pointer to a char to indicate the end of the parsed portion of the input string.

            Major codebases performing high-level operations on data that’s shared in barely trackable scopes certainly aren’t best implemented in C. It’s still the language of choice for low-level code, especially on embedded systems, where allocations are not taken lightly.

  • xmunk@sh.itjust.works
    link
    fedilink
    arrow-up
    25
    ·
    3 months ago

    Once your pointer definition looks like a censored swear word you’re doing something awful.

    In my entire programming career I’ve used int ** less than a handful of times and I’ve always been borderline about refactoring when I need it.

    • CanadaPlus@lemmy.sdf.org
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      3 months ago

      Okay, but what if you’re dealing with a rather high-dimensional tensor? In some kinds of coding it can happen, and you usually don’t want to sacrifice performance when it does.

      You can also do increasingly elaborate pointer arithmetic, but that seems worse, not better to me.

  • MajinBlayze@lemmy.world
    link
    fedilink
    arrow-up
    20
    ·
    edit-2
    3 months ago
    *char // I heard it from a friend
    **char //who heard it from a friend
    ***char // who heard it from another
    "You were messing around"
    
  • RonSijm@programming.dev
    link
    fedilink
    arrow-up
    10
    ·
    3 months ago

    Me: building a fluent interface framework…
    I already support a WrapperOf<T, T, T, T>
    User: Can I have a WrapperOf<T, T, T, T, T> because I’m doing something weird?
    Me: *sigh* god-damnit. You’re right but I still hate it.

    • renormalizer@feddit.org
      link
      fedilink
      Deutsch
      arrow-up
      5
      ·
      edit-2
      3 months ago

      I’ve been a four-star programmer a few times. Imagine a blocked symmetric matrix where the rows and columns are indexed by triples (u,v,w). The entries are zero whenever u != u’ or v != v’, and because of symmetry you only store entries with w <= w’. But the range of v depends on the value of u and the range of w on the value of v. So you do

      double ****mat = calloc (UMAX, sizeof(*mat));
      for (int u = 0; u < UMAX; ++u) {
        mat[u] = calloc (u + 1, sizeof(**mat));
        for (int v = 0; v <= u; ++v) {
          mat[u][v] = calloc (v + 1, sizeof(***mat));
          for (int w = 0; w <= v; ++w) {
            mat[u][v][w] = calloc (w + 1, sizeof(****mat));
            for (int ww = 0; ww <= w; ++ww)
              mat[u][v][w][ww] = some_function (u, v, w, ww);
          }
        }
      }
      

      and weep a little. In reality, this gets a bit optimized by allocating a single chunk of memory and carving that up into the pointer and data arrays, so everything is reasonably close together in memory.

    • calcopiritus@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      3 months ago

      If you do it with fixed-size arrays you can accomplish multi-dimension with just int*. Lots of pointer arithmetic needed though. Probably still faster than n levels of indirection.