• @nous@programming.dev
    link
    fedilink
    English
    133 days ago

    Just because a feature was not rolled out in the mid-90s would that mean that it’s not available today?

    Adding a feature is one thing, C++ has added a lot of memory safety features over the years. The problem with C++ is it still allows a lot of unsafe ways of working with memory that previous projects used and people still use now. Removing support for these features will break existing code and piss a lot of people off in the process. It is not about adding new features, but removing the unsafe existing features that they are talking about here.

    • @lysdexic@programming.devM
      link
      fedilink
      English
      -63 days ago

      The problem with C++ is it still allows a lot of unsafe ways of working with memory that previous projects used and people still use now.

      Why do you think this is a problem? We have a tool that gives everyone the freedom to manage resources the way it suits their own needs. It even went as far as explicitly supporting garbage collectors right up to C++23. Some frameworks adopted and enforced their own memory management systems, such as Qt.

      Tell me, exactly why do you think this is a problem?

        • It’s not just that. Debugging segfaults and UB can be an absolute nightmare.

          The C++ committee still haven’t learnt their lesson. I recently learnt about C++20 coroutines, which are pretty neat, if complex (there are pretty much no good learning resources about them). However they are still putting unnecessary UB footguns in it.

          • lad
            link
            fedilink
            English
            21 day ago

            Reminds me of how I found some safety measures to be in China some years back, basically those were signs saying “plz don’t fall to your death, if you do it’s your fault”