aka “bros: in order to be rich, just don’t be poor.”

  • Masterkraft0r@discuss.tchncs.de
    link
    fedilink
    arrow-up
    2
    ·
    4 hours ago

    he didn’t say that

    he said once that static analysis of c++ is not possible because of the halting problem though

    and he did create c++, which i use daily

    i find it to be the language for other languages to learn how to absolutely not do it

    it is the programming equivalent of that first scene in scary movie 1 where the woman first picks the banana instead of the gun and then runs in the direction “danger” instead of “safety” and gets run over by her distracted dad getting a blowjob in the car

  • JakenVeina@midwest.social
    link
    fedilink
    arrow-up
    49
    ·
    2 days ago

    To be clear, he’s not saying “just code better”, as the title implies. It’s a really poor choice of title.

    you are going to mess up somewhere and get leaks, stray pointers, etc. This is true independently of how conscientious you are with your allocations:

    He goes on to say, effectively, “Don’t use new/delete/malloc/free if you can help it. Use smarter mechanisms.”

    • sik0fewl@lemmy.ca
      link
      fedilink
      arrow-up
      5
      ·
      1 day ago

      Ya, I don’t think he actually said that since it’s not mentioned in the referenced article. What’s actually meant is “by writing code that doesn’t have any memory management”.

    • avocado@programming.dev
      link
      fedilink
      arrow-up
      3
      arrow-down
      3
      ·
      1 day ago

      C++'s so called smarter mechanisms are ugly af. I would rather my RAM crash and burn than use its standard library.

      • chunes@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        1 day ago

        yeah. I’d rather use C and statically allocate everything up front, even if that’s not a great fit

        • sobchak@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          20 hours ago

          When I did embedded programming that’s what I did. Nothing was dynamically allocated. It also allowed me to write a debugger that would watch how variables changed by just directly reading from memory, chart them, and and stuff like that.

  • moonpiedumplings@programming.dev
    link
    fedilink
    arrow-up
    29
    ·
    2 days ago

    No, this is kinda right. Memory leaks =/= memory safety. Memory leaks are just when you keep allocating more and more memory, and can be done in any language. If I make accidentally make a list that infinitely grows in python, that’s a memory leak.

    There are techniques to write code that is mostly free of leaks, which is what he is referring to.

    Memory safety, on the other hand, doesn’t seem to be mentioned on that page…

    • BradleyUffner@lemmy.world
      link
      fedilink
      English
      arrow-up
      12
      ·
      edit-2
      1 day ago

      A “true” memory leak isn’t just memory that is never freed, it’s memory that CAN’T be freed. Usually because the handle / pointer to it was thrown away.

      The distinction isn’t really all the important though, it all looks the same as far as how the program functions.

  • ISO@lemmy.zip
    link
    fedilink
    arrow-up
    18
    arrow-down
    7
    ·
    2 days ago

    A reminder that Bjarne doesn’t actually code. He is a bureaucrat.

  • lime!@feddit.nu
    link
    fedilink
    arrow-up
    15
    arrow-down
    6
    ·
    2 days ago

    all these newfangled languages with their “memory safety” and “helpful tooling”, pah. all a real programmer needs is a hole punch and a roll of paper.

  • TehPers@beehaw.org
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 days ago

    The memory leaks section just feels like an introduction to smart pointers as though they’re some complex concept. Also, the page is showing its age by mentioning the now-removed auto_ptr instead of something like unique_ptr.

    Anyway, scrolling down a little more:

    Why can’t I assign a vector<Apple*> to a vector<Fruit*>?

    This actually comes up in C# with arrays. Copying their example here:

    object[] array = new String[10];
    // The following statement produces a run-time exception.
    // array[0] = 10;
    

    It may have been a design mistake not to make C#'s arrays invariant, though I don’t know the state of that debate today.

      • gedhrel@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        2 days ago

        Neither covariant nor contravariant.

        supertype[] is not a supertype of subtype[] if supertype and subtype alone are in that relationship, because the mutability of arrays means that the Liskov substitution principle doesn’t hold.

        (These are all something you’ll probably find good explanations of on Wikipedia.)

        • tabular@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 days ago

          Thank you for your reply. Sadly I don’t know terms like covariant or supertype either 😅 so I’ll have to look into all that when/if it comes up. I write in GDScript for fun (a game engine’s high-level scripting language said to have syntax similar to Python).