• Moussx
    link
    fedilink
    arrow-up
    167
    arrow-down
    5
    ·
    9 months ago

    “Oh, so we’re actually not friends” Walks away, as she should

  • Murvel@lemm.ee
    link
    fedilink
    arrow-up
    57
    arrow-down
    3
    ·
    edit-2
    9 months ago

    Ohhh gottem!

    She is now legally obligated to sex this man.

    edit: programmers code

  • lowleveldata
    link
    fedilink
    arrow-up
    20
    arrow-down
    2
    ·
    9 months ago

    What’s the point of having friends when the whole point of private fields is to ensure that you don’t break other parts when changing those?

    • NightAuthor@lemmy.world
      link
      fedilink
      English
      arrow-up
      15
      ·
      9 months ago

      It’s just another option, don’t gotta use it. Maybe you find yourself needing something like this, and the only other choice is making it public. At least with friend classes, you know which classes are friends so you can go look for any dependencies

      • lowleveldata
        link
        fedilink
        arrow-up
        4
        ·
        9 months ago

        It’s just another option, don’t gotta use it

        It’s not a choice of mine when I’m trying to read through / modify some legacy code base

        • owen@lemmy.ca
          link
          fedilink
          arrow-up
          7
          ·
          9 months ago

          Meh, that already comes with infinite problems, so what’s one more?

    • Codex@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      9 months ago

      There’s infinite ways to organize code. In C# or Rust where this isn’t an option, you might use nested classes or traits hidden behind a module/namespace.

      Good use cases are data structures with associated helper classes. For example, a collection/tree and an iterator/tree-walker for working with elements of the collection. Or for something like a smart memory allocator (an arena or slab allocator), you might use a friend-class to wrap elements returned from the allocator, representing their connection back to it (for freeing up when done or to manage the allocation structure in ie a heap or sorted tree).

  • Ziglin@lemmy.world
    link
    fedilink
    arrow-up
    8
    arrow-down
    2
    ·
    9 months ago

    Does C++ actually have something like that? That sounds like something made up for the joke?

      • Ziglin@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        9 months ago

        Huh, do Java and other oop languages have them too and what are some good reasons to use them?

        • UnfortunateShort@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          9 months ago

          It allows for more fine grained access control and to implement afterthoughts.

          Think having some private function that can break things if called improperly, but also allow you to avoid significant overhead when calling it the correct way. For example you could be avoiding input validation in a public wrapper for that function. If your friendly class already does it, or cannot produce invalid inputs, there is no need for that.

          You could also implement logging after the fact, because your friendly logger object to read private members.

          Arguably it’s a questionable design decision tho, as you could do all of this in other ways and it basically breaks any guarantees private would usually give you.