3 ms·

Yep, but that doesn't help so much when you're writing a framework or library and want to ensure the user can't mess it up (although current Haskell couldn't he

Yep, but that doesn't help so much when you're writing a framework or library and want to ensure the user can't mess it up (although current Haskell couldn't help with that either, given there's no way to prohibit the user writing unsafe code).

pjmlp 6y ago
Just like in languages like C++ you cannot force stack allocation/global memory segments, which is the only way to make RAII work. A new without delete, not only causes a memory leak, it also leaks whatever else could be released by the destructor. Same applies to Rust when heap memory gets forgotten.
- AnimalMuppet 6y ago
  > Just like in languages like C++ you cannot force stack allocation/global memory segments, which is the only way to make RAII work. Could you explain a bit more about what you mean here? To me, RAII is about how the constructor is written, and stack allocation/global memory segments are about where the object is created. I don't see any connection between the two. For example, if I have a class with a custom allocator that allocates from its own arena, I can still do RAII on the members of objects of that class... can't I?
  - pjmlp 6y ago
    Yeah, but how are you supposed to release the data stored in the area and the owning class, if the destructor doesn't get called? As an example (ignore possible compile errors), // in mylib.h namespace mylib { template<class allocator = default_arena> class ArenaString final { public: ArenaString(); ~ArenaString(); // several String related methods private: ArenaAllocator<allocator> stringData; }; // several utility functions ArenaString* StringFactory() { return new ArenaString(); } } // now on main.cpp #include "mylib.h" void myLeakyFunction() { auto strPtr = mylib::StringFactory(); // do something with strPtr //oops, strPtr is now gone and ArenaString::~ArenaString() won't get called } Alternatively, which I think is the main point of your question, one could call something like myArena::clean() somewhere up the call stack to myLeakyFunction. But then the question about class instances surviving the region as empty shells with a corrupt state in their stringData member data arises. While this example is made on purpose to illustrate my point, on big code bases (specially with libraries that one doesn't have any kind of control) it can lead to bad code that prevents RAII patterns to work as expected. Code that most developers on the team won't even realize it is there and probably will spend hours trying to find out what is wrong with the memory management.
    - AnimalMuppet 6y ago
      OK. So "RAII" means what I meant by RAII (just the constructor technique) plus the rest of the normal memory management approach (destructors). And if it's not stack allocated (or a member of a class that is), you don't get destructors automatically called. I get it. The only thing I'm left confused about is "global memory segments". How does that fit in? If it's a global it's never destroyed, so you don't have to worry about it? Or did you mean something else?

pjmlp 6y ago

Just like in languages like C++ you cannot force stack allocation/global memory segments, which is the only way to make RAII work. A new without delete, not only causes a memory leak, it also leaks whatever else could be released by the destructor. Same applies to Rust when heap memory gets forgotten.

AnimalMuppet 6y ago
> Just like in languages like C++ you cannot force stack allocation/global memory segments, which is the only way to make RAII work. Could you explain a bit more about what you mean here? To me, RAII is about how the constructor is written, and stack allocation/global memory segments are about where the object is created. I don't see any connection between the two. For example, if I have a class with a custom allocator that allocates from its own arena, I can still do RAII on the members of objects of that class... can't I?
- pjmlp 6y ago
  Yeah, but how are you supposed to release the data stored in the area and the owning class, if the destructor doesn't get called? As an example (ignore possible compile errors), // in mylib.h namespace mylib { template<class allocator = default_arena> class ArenaString final { public: ArenaString(); ~ArenaString(); // several String related methods private: ArenaAllocator<allocator> stringData; }; // several utility functions ArenaString* StringFactory() { return new ArenaString(); } } // now on main.cpp #include "mylib.h" void myLeakyFunction() { auto strPtr = mylib::StringFactory(); // do something with strPtr //oops, strPtr is now gone and ArenaString::~ArenaString() won't get called } Alternatively, which I think is the main point of your question, one could call something like myArena::clean() somewhere up the call stack to myLeakyFunction. But then the question about class instances surviving the region as empty shells with a corrupt state in their stringData member data arises. While this example is made on purpose to illustrate my point, on big code bases (specially with libraries that one doesn't have any kind of control) it can lead to bad code that prevents RAII patterns to work as expected. Code that most developers on the team won't even realize it is there and probably will spend hours trying to find out what is wrong with the memory management.
  - AnimalMuppet 6y ago
    OK. So "RAII" means what I meant by RAII (just the constructor technique) plus the rest of the normal memory management approach (destructors). And if it's not stack allocated (or a member of a class that is), you don't get destructors automatically called. I get it. The only thing I'm left confused about is "global memory segments". How does that fit in? If it's a global it's never destroyed, so you don't have to worry about it? Or did you mean something else?