RAII Abstractions

[Cons-Cat]

I'm lazy, and don't like freeing memory on my own when a low-cost abstraction exists to do it for me. vulkan.hpp provides an RAII abstraction around its Vulkan objects to handle freeing them. I think this makes a lot of sense for many Vulkan objects that exist within a clearly known lifetime. For instance, lava::app can be assumed to exist only inside the scope of main(), and live throughout all of it. Most (or all?) of the current examples also only have Vulkan object with known lifetimes, as well.

There doesn't seem to be anything special about how the destroy() methods in the lava objects are called by a user (only where in the program matters, and only sometimes), so maybe they could be automated, and a lot of Vulkan programmers seem to think that RAII makes a lot of sense for graphics programming. I know that some Ziguanas disagree, but their preferred pattern isn't possible in C++.

I imagine most objects can fall out of scope and have their destroy() method called automatically, and this wouldn't cause any issues so long as it is easy to factor between RAII objects and non-RAII objects. To achieve that, Nvidia decided that all their Vulkan objects are in a vk:: namespace, and the RAII abstractions inside a vk::raii:: namespace. So for instance, there is both a vk::Instance and a vk::raii::Instance object. Changing one into the other is as simple as changing the scope resolution. I imagine something similar with lava::instance and lava::raii:instance, lava::mesh and lava::raii::mesh, etc.

I'm not sure how best this could be implemented. Maybe the methods and all fields except for ptr can be in a private struct, and the front facing lava::mesh and lava::raii::mesh inherit from this struct while also defining std::shared_ptr<mesh> and std::unique_ptr<mesh> respectively? The ::raii objects would also need a destructor to replace destroy(), if I understand correctly.

vulkan.hpp provides its samples with both explicit and raii deallocation, so programmers who have a preference can learn the tool either way.

What do you think about the idea? Would it be worthwhile for me to make a prototype?

[TheLavaBlock]

Thank you for the detailed description of your request. I will give more thought to this and take a closer look at examples. Maybe we'll come up with an improvement soon.

I am quite satisfied with the current implementation which is described in the Guide/Lifetime of an Object