5 ms·
To me, "Rule of Zero" sounds more like not implementing {con,copy-con,de}structors, i.e. forgoing RAII. I've been doing this quite a lot, and it makes writing l
by ambrop7 14y ago
To me, "Rule of Zero" sounds more like not implementing {con,copy-con,de}structors, i.e. forgoing RAII. I've been doing this quite a lot, and it makes writing low-level and optimized code so easier.
Actually, I find that having fixed ownership makes much more sense than reference counting for the majority of cases. Example: we have a FileSystem, and a bunch of File's belonging to this FileSystem. Whenever a part of a program needs a file, it just initializes its own File object, and when it doesn't need it anymore, it releases it somehow (e.g. file.deinit() or destructor if RAII is used). Even if two users both need the same file, each gets its own File. The FileSystem internal implementation can take care of any resources sharing, invisible to the users.
As far as the memory management of FileSystem is concerned: again, in most cases, you don't need shared_ptr<FileSystem>. Just make sure the FileSystem stays alive as long as there's the possibility that anyone is using it. Like initialize it at the beginning of the program, and deinitialize it during shutdown at the right point.
- mpyne 14y agoThis "Rule of Zero" construct doesn't forgo RAII, since RAII does not simply mean "write constructors and destructors". Instead it allows the compiler and language to automatically do the right thing to enable RAII by using appropriate library-provided building blocks. E.g. his std::unique_ptr + custom deleter type enables the compiler to automatically make a RAII-compliant class for the author, so it's still RAII, just automatically implemented (except for the ctor, in this case).