3 ms·

"A key innovation of C++ was to introduce RAII, which essentially ‘piggybacks’ on the value of the stack and enriches it with a lot more power." I haven't writ

"A key innovation of C++ was to introduce RAII, which essentially ‘piggybacks’ on the value of the stack and enriches it with a lot more power." I haven't written C++ in two decades, but it was my impression that heap allocated resources are not on the stack. The major problem with C++ isn't resources can be used used after freed, it's that they are never freed if you don't clean up when your RAII is popped off the stack via destructor or other "event handler methods". Isn't RAII more of a pattern implemented atop the core constructor/destructor? It's kind of a stretch to call it a fundamental feature of C++ like GC is to java/jvm. Has valgrind "solved" memory leaks as a primary concern/danger in C++?

RcouF1uZ4gsC 6y ago
RAII is a core fundamental feature of C++ and I would argue that constructors and destructors are the implementation. With RAII (using vector, string, unique_ptr, etc), memory leaks are pretty much a solved problem in modern c++. The biggest memory danger in C++, in my opinion, is dangling references where you have a reference to an object (either on the stack or heap) that has been destructed.
ChrisSD 6y ago
The idea in RAII is you create a type that's solely responsible for acquiring the resource and freeing it (and little else). This idea is indeed fundamental to modern C++ design. For example, smart pointers. When created, the pointer lives on the stack. The resource it points to lives elsewhere but that's no concern to RAII. When the stack variable goes out of scope the resource will automatically be freed (via the destructor) One place where this can break down in C++ is in copy and moves. The acquire/release works simply enough using constructors/destructors but correctly handling copies and moves has turned out to be harder to get right. And when you add in other objects that may refer to the resource object... well things can quickly become even harder to handle unless you're very careful.
hawski 6y ago
What's a fundamental feature for C++ then, if not RAII? GC may not be the fundamental feature of Java the language, but it is certainly a fundamental feature of JVM.
bluGill 6y ago
You should look into modern c++ - at least C++11. While it is possible to write the code with all the problems you state, C++11 adds some neat features that mean in practice you rarely do. Sure I can put something on the heap and forget to free it - but in practice I don't put anything on the heap without first wrapping it in something on the stack so that when the thing on the stack goes away my thing on the heap does too. This can get really complex fast to deal with edge cases, but most of the time the complexity is hidden and so doing the right thing that always works is just as easy as putting something on the heap that I have to remember to free latter. Most people use address sanitizer not valgrind for the few times they have a memory leak. In general though the problem is solved not by tools but by using the modern C++ features. Valgrind is really only useful when you need to deal with C interfaces. (note interfaces, the code on either side need not be written C)

RcouF1uZ4gsC 6y ago

RAII is a core fundamental feature of C++ and I would argue that constructors and destructors are the implementation. With RAII (using vector, string, unique_ptr, etc), memory leaks are pretty much a solved problem in modern c++. The biggest memory danger in C++, in my opinion, is dangling references where you have a reference to an object (either on the stack or heap) that has been destructed.

ChrisSD 6y ago

The idea in RAII is you create a type that's solely responsible for acquiring the resource and freeing it (and little else). This idea is indeed fundamental to modern C++ design. For example, smart pointers. When created, the pointer lives on the stack. The resource it points to lives elsewhere but that's no concern to RAII. When the stack variable goes out of scope the resource will automatically be freed (via the destructor) One place where this can break down in C++ is in copy and moves. The acquire/release works simply enough using constructors/destructors but correctly handling copies and moves has turned out to be harder to get right. And when you add in other objects that may refer to the resource object... well things can quickly become even harder to handle unless you're very careful.

hawski 6y ago

What's a fundamental feature for C++ then, if not RAII? GC may not be the fundamental feature of Java the language, but it is certainly a fundamental feature of JVM.

bluGill 6y ago

You should look into modern c++ - at least C++11. While it is possible to write the code with all the problems you state, C++11 adds some neat features that mean in practice you rarely do. Sure I can put something on the heap and forget to free it - but in practice I don't put anything on the heap without first wrapping it in something on the stack so that when the thing on the stack goes away my thing on the heap does too. This can get really complex fast to deal with edge cases, but most of the time the complexity is hidden and so doing the right thing that always works is just as easy as putting something on the heap that I have to remember to free latter. Most people use address sanitizer not valgrind for the few times they have a memory leak. In general though the problem is solved not by tools but by using the modern C++ features. Valgrind is really only useful when you need to deal with C interfaces. (note interfaces, the code on either side need not be written C)