6 ms·

> If you imagine destructors have something to do with memory management, you have much yet to learn. It is very limiting to think that destructors is the only

• masklinn 5y ago
  What alternative doesn’t add failure opportunities and require additional work by the developer where they will crop up? Both defer (and more generally scope guards) and context managers certainly do, to say nothing of try/finally.
  • pjmlp 5y ago
    True, but also does RAII for heap allocated objects unless one makes use of smart pointers. Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.
    • masklinn 5y ago
      I don't understand the objection (?), I think there's at least one word missing, possibly more. If you want to use RAII for heap allocations you obviously need some sort of RAII wrapper for them. And smart pointers are the usual solution. But technically you can do without if you really really don't want to make dereference overridable, you can just have the "smart" bit (RAII / automatic deterministic deallocation) without the "pointer" bit.
      • pjmlp 5y ago
        What your obviously remark misses out is my second sentence "Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.". I have seen plenty of new std::string("some") and other similar crimes in offshored code, or code without ownership that gets updated by whatever external contractor got brought in to implement 5 Jira tickets that finally got some budget assigned to them. To be fair this isn't exclusive of C++, I have seen similar bad practices in other languages, C++ just gives more opportunities for them.
        • masklinn 5y ago
          > What your obviously remark misses out is my second sentence "Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.". Right, but we're not discussing C++ are we? We're discussing RAII. C++'s mistakes are C++'s mistakes, adding RAII to a language doesn't imply you have to replicate C++'s mistakes, nor are C++'s mistakes issues with the concept of RAII, or destructors.
          • pjmlp 5y ago
            Had RAAI been properly implemented in C++, doing something like new std::string("something") should have been a compiler error. From type theory point of view, ideally RAII aware types should only compose with outher RAII types without escape hatches. Rust and Ada do it better in this regard.
            • ncmncm 5y ago
              What do you imagine is typologically wrong with new std::string("pjmlp")? Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom; and std::string is limited (expect unicode-aware strings in '23). But a heap-allocated string object is a thing equally easy and useful to express in Rust. (Dunno about Ada: does it have any analog of destructors, yet?)
              • masklinn 5y ago
                > What do you imagine is typologically wrong with new std::string("pjmlp")? You have to remember to `free` the string explicitely. > Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom Is it? Isn't that going to create an `unique_ptr<char*>`?
                • ncmncm 5y ago
                  Nope: https://en.cppreference.com/w/cpp/string/basic_string/operator%22%22s https://en.cppreference.com/w/cpp/string/basic_string/operat... > You have to remember to `free` the string explicitly That is not a type problem. It is far from clear what pjmlp means here. unique_ptr should have been invented in 1985? Time machines have their own problems.
    • sagarm 5y ago
      unique_ptr is simple and and easy to use for individually managed memory. shared_ptr can dramatically simplify some concurrent code, as well. For arena allocated memory, you have to manage the lifetimes manually just as you would for C -- except that the arena itself can be lexically scoped, at least. C++ is not a perfect language by any means, but destructors are not a mistake IMO. I too find having to manually "defer" cleanup annoying. I'm still interested in zig for the comptime features, though.
  • bvrmn 5y ago
    Linear types can solve the problem. Also destructors tie design to stack frames. Limiting application for strictly nested code only.
    • masklinn 5y ago
      > Linear types can solve the problem. While that is true, I did not consider it worth mentioning given the context of the discussion. I still don't. > Also destructors tie design to stack frames. No more so than linear types.