4 ms·
As with most C++ terms, it means something completely perpendicular to what it implies. In general it means that deterministic destructors release a resource at
by pie_flavor 4y ago
As with most C++ terms, it means something completely perpendicular to what it implies. In general it means that deterministic destructors release a resource at the moment the value representing it goes out of scope, e.g. deallocating memory or closing a file handle.
IMO Odin is very wrong on this point: the important thing about destructors is that you know where to find them, so e.g. you can have closures that know how to free their captures when they are freed. There's nothing like that for Odin.
- unsafecast 4y agoOdin doesn't even have closures, or any feature that requires this kind of RAII. The whole point here is that the language doesn't deallocate for you.
- pie_flavor 4y agoI know. You say that like it's a good thing.
- unsafecast 4y agoThere's value in having a straightforward language where you know what's going to happen at any given moment. It's not good for everyone (and -thing), but languages like these have to exist, and they're needed for good reasons.
- pie_flavor 4y agoIf I call a closure, I know what's going to happen - the closure is going to get called. Unless you are talking about the virtual jump, in which case that ship has sailed because Odin has function pointers. This is an allergic reaction to anything more useful than C, not a real complaint.
- _gabe_ 4y ago> the important thing about destructors is that you know where to find them The problem isn't that programmers have trouble finding a destructor. The problem is it's not apparent looking at any snippet of C++ code which objects have destructors running additional cleanup logic or other extra code without looking up each class declaration and verifying. I believe Odin is trying to solve this by forcing the programmer to make this code explicit, but reduce the number of footguns by allowing the programmer to keep the initialization and free close to each other.
- Rusky 4y agoBut this just shifts the problem. Now it's not apparent looking at any snippet of Odin code which objects should have cleanup logic but don't, without looking up each type and reading its documentation.
- gingerBill 4y agoYou can apply that exact same logic to languages with RAII, e.g. C++. "It's not apparently looking at any snippet of C++ code which objects have constructors and destructors, without looking up each type and reading its documentation." Note the difference here is between being implicit vs explicit, and obvious vs hidden. RAII is implicit and hidden, which may not be a good thing in certain projects, especially when copy constructors are being called all over the place. (And move semantics don't replace copy constructors in different places, only help reduce the use of them in many cases)
- Rusky 4y agoYes, that is what I replied to... my point was that neither approach is a pure improvement over the other.
- pie_flavor 4y agoI didn't say programmers have trouble finding it. My example, closures automatically calling it, is about the compiler knowing where to find it. It does not reduce the number of footguns when you have to manually free every resource, no.