5 ms·

Yeah, sounds like someone doesn't understand lifetimes and RAII. Even in modern C++ the number of times you have to actually think about memory management inste

• david422 5y ago
  Even then, just add a wrapper and off you go.
• tsimionescu 5y ago
  But thinking about lifetimes and RAII is 90% of memory management. Basically whether you write C, C++, or Rust, you have to track ownership the same ways, the only thing that changes is how much the compiler helps you with that. However, if you write your program in Java, Lisp or Haskell, you simply do not care about ownership for memory-only objects, and can structure your program significantly differently. This can have significant impact on certain types of workflows, especially when it comes to shared objects. A well-known example is when implementing lock-free data structures based on compare-and-swap, where you need to free the old copy of the structure after a successful compare-and-swap; but, you can't free it since you don't know who may still be reading from it. Here is an in-depth write-up from Andrei Alexandrescu on the topic [0]. Note: I am using "object" here in the sense from C - basically any piece of data that was allocated. [0] http://erdani.org/publications/cuj-2004-10.pdf http://erdani.org/publications/cuj-2004-10.pdf
  • bluGill 5y ago
    With modern C++ your memory checklist is two steps: put it on the stack, put it in a unique_ptr on the stack. There are more steps after that, but you almost never get to them and wouldn't remember them if you discovered the need for them (which is okay because you never get there).
    • tsimionescu 5y ago
      Your checklist is only covering the simplest case, direct ownership of small data structures. I'm not going to put a large array on the stack. I'm not going to pass unique_ptr (exclusive ownership) of every resource I allocate to every caller. I still need to decide between passing a copy, a unique_ptr, a reference, or a shared_ptr. When I design a data structure with interior pointers, I need to define some ownership semantics and make sure they are natural (for example, in a graph that supports cycles, there is no natural notion of ownership between graph nodes). These are all questions that are irrelevant in a GC langauge, for memory resources.
      • pjmlp 5y ago
        Not really irrelevant when the said GC language also does value types, e.g. // C# Span<byte> buffer = stackalloc byte[1024];
        • tsimionescu 5y ago
          True, but even then you only have to decide between passing a copy of the value or a reference to it, no need to think about ownership.
          • pjmlp 5y ago
            Kind of, if it is a struct with destructors you need to ensure a region exists. So either do something like using MyStructType something = new MyStructType () Or a more FP like stuff with myVar.WithXYZResource(res => { /* .... */ }) And then consider if it should be a ref struct, so that is only stack allocated. This from C# point of view, in something like D, there would be another set of considerations. Still much easier than "in your face ownership management" though, yes.
            • tsimionescu 5y ago
              Well, destructors come up if you have non-memory resources to manage, and there you do go back to ownership and deterministic destruction issues.
    • UncleEntity 5y ago
      > … put it on the stack, put it in a unique_ptr on the stack. What happens when the stack frame gets destroyed but you kept a reference to the data around somewhere because you needed it for further compilation? I, for one, am a fan of using the heap when doing the C++ things…
• pjmlp 5y ago
  I guess something like Android Oboe, macOS DriverKit, Windows Runtime C++ Template Library, or C++/WinRT could be considered old libraries then.