Comments by "gingerBill" (@GingerGames) on "Computerphile" channel.

This video conflates RAII and ownership semantics quite a bit. This is a common misconception but if this is meant to be an introduction to either concept, this will most definitely confuse a newcomer to these concepts. You can explain Ownership Semantics without ever referring to RAII whatsoever and vice versa. Ownership semantics can be used to aid with a few issues that RAII in C++ causes (such as over use of copy constructors) but they solve different orthogonal problems entirely. C++11 onwards also has all of these ownership semantics (rvalue references, std::move, std::forward, etc), but they are an opt-in thing rather than something that is required like in Rust. Also, if you are wanting to reduce resource usage as much as possible, RAII is not the right tool for you and will most likely cause you to waste more memory than other approaches.
71
@noahhounshel104 @kwanarchive @Zsombor Hollay RAII on its own does not necessarily waste memory compared to other approaches, however the general culture assumes RAII means you should allocate singular things instead of thinking about your allocation separately from your single objects. As a result, a lot of memory is wasted because you off-load the allocation aspect to the single object, whereas RAII could still be useful if you did not do this. Another issue with C++ specifically is that they conflate construction/destruction with allocation/deallocation. It is extremely useful to want to allocate an object and then construct it at a later time, destruct it and then deallocate it at a later date, but due to the way C++ has been designed and the culture around C++, most people couple them together (making things bad). Constructors and destructors also do not "return a value" meaning that the only way you can signal something may have gone wrong is by throwing an exception (which might be a huge issue depending on the problem space). This is why many people will just use explicit `init` and `destroy` functions/methods instead of relying on the ctors/dtors, thus bypassing many of the features of RAII. I can give you loads of real world examples of codebases that use RAII heavily that are extremely wasteful of memory (compared to other approaches). And to clarify, RAII is not inherently wasteful but the culture around it and how it the languages that have tend to be designed nudge you to use it in such a way that is extremely uncaring about memory allocations by making them hidden.
6
@noahhounshel104 I am not sure why brought up RAII and `Option<&T>` when that specific example is an option of a reference of T, meaning it does not have any useful `drop` call associated with it. `Option` types in general can be useful in languages such as Rust but it's completely orthogonal to RAII still. And how people actually use RAII does mean that they rarely defer the creation of the objects to a late date, and because of how languages like C++ (and Rust to a less extent due to the lifetime semantics) have been designed and the culture that has grown around them, does mean people do couple allocations and creation. You cannot ignore how people use a tool in practice.
4
What is the name of the convention where the parameter types of functions are declared afterwards? E.g. int main(argc, argv) int argc; char** argv; {}
1