Scope-based resource management for the kernel

Posted Jun 17, 2023 7:00 UTC (Sat) by ibukanov (subscriber, #3942)
In reply to: Scope-based resource management for the kernel by mbunkus
Parent article: Scope-based resource management for the kernel

There are two separated questions. RAII as a paradigm and RAII as it is implemented in C++.

From a system/emebeded programming point of view I would rather prefer if C++ would require explicit destructor calls for RAII rather than calling destructors automatically. Yes, it will make code more verbose, but at least it will make very obvious what the code is doing. And it will prevent a few bugs due to unexpected destruction of temporaries. For C such enforcement of destructor-type calls will be even more natural that the current attribute hack.

Scope-based resource management for the kernel

Posted Jun 17, 2023 7:31 UTC (Sat) by mbunkus (subscriber, #87248) [Link] (2 responses)

The whole idea of RAII is automatic freeing of the acquired resources in order to prevent memory leaks. Additionally in C++ you get the nice property that you have deterministic behavior when the resource is freed: when the life of the object holding the
resource ends.

Manual calls to destructors are not RAII. You don't gain any of RAII's advantages by requiring manual calls to free the resource.

Scope-based resource management for the kernel

Posted Jun 18, 2023 14:46 UTC (Sun) by ibukanov (subscriber, #3942) [Link] (1 responses)

The idea is that the compiler requires explicit destructor calls exactly at the places where presently it inserts it automatically.

Scope-based resource management for the kernel

Posted Jun 19, 2023 0:32 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

Linear aka Use-exactly-once types. C++ isn't very well suited for this kind of types. Neither is Rust. There are languages which thrive on linear types and a few newer ones are purpose built for these types.

Scope-based resource management for the kernel

Posted Jun 18, 2023 21:13 UTC (Sun) by nksingh (subscriber, #94354) [Link] (1 responses)

I would instead prefer a paradigm like WordPerfect's 'reveal codes', where the compiler and editor can display the code that the compiler is injecting as an option rather than needing to have the code visible at all times.

The advantage of producing the code as needed for review/debugging rather than requiring it to be explicit: when editing, your code remains flexible and modifiable with the compiler doing the bookkeeping at the end, rather than you having to compensate for changes manually before you can even test your code out. I think for domains like embedded, high performance, and kernel code, this transform between 'debuggable' and 'editable' source code would help satisfy both people who want productivity and those who want to know exactly what will happen in the CPU.

Scope-based resource management for the kernel

Posted Jun 26, 2023 6:13 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

Then it should all be implemented in the editor.

Scope-based resource management for the kernel

Posted Jul 2, 2023 17:05 UTC (Sun) by bluss (guest, #47454) [Link]

Non-trival C++ functions have two exit paths: the return statement (if a single one) and when unwinding an exception. To be fully explicit, one needs to write out destructor calls that happen in both those cases(!).