RAII deleters with dependencies

[JohnyTheCarrot]

A point often raised by people is that RAII isn't always possible.

One such example using Vulkan:

• A VkBuffer object may be created on a VkDevice.
• To destroy the buffer you need both the VkBuffer and VkDevice:

void vkDestroyBuffer(
    VkDevice                                    device,
    VkBuffer                                    buffer,
    const VkAllocationCallbacks*                pAllocator);

Imagine an owner that holds one VkDevice handle and a number of VkBuffers.
In an ordinary situation, the owner can iterate over the VkBuffer container and call vkDestroyBuffer using its VkDevice member.
Each VkBuffer's memory footprint is simply the size of its handle type, as the owner holds the VkDevice handle.

In RAII as I understand it, using a unique_ptr would require each such instance owned by the aforementioned owner hold the same VkDevice handle, effectively doubling the memory footprint of each handle.

One solution I could think of is to contain the VkDevice in a Singleton (the kind I.3 Avoid singletons declares an exception) but that is quite restricting and a whole thing with regards to the lifetime of the VkDevice.

I was wondering if I somehow missed existing discussions or advice on this instance?

Thanks!

[Sqeaky]

Tldr: Sometimes you have to compromise on best practices with regards to engineering practicalities.

RAII doesn't need to be unique_ptr instances. They are just one convenient way to achieve the result. In general, acquiring resources on construction and then releasing on destruction is the goal of pattern. It's the pattern is even right for your problem.

If I ran into a situation where I had to have two objects and they needed to be created in conjunction or destroyed in conjunction and I wanted to use RAII, then I would make some single object that did that correctly where all the resources involved. I would create both in the constructor and destroy both of the destructor. I would pay attention to the semantics on copy and move and determine if those were valid and delete those constructors if they were not. But it doesn't sound like you need pairs of objects. It sounds like you might have a one to many relationship between objects.

You touch on another possibility, a trade off costing memory and object size. If you need different amounts of these, or any objects with a one to many relationship, you could have some tracking between objects. If the destructor for each of the many objects needs some sort of handle to the one, you could put a pointer in every one of the many objects back to the one they depend on. You're right that this increases their size, but in practice is there actually a problem? Sometimes it will generate too much cache pressure, memory use, or runtime cost, but I don't know your use case. It generally isn't slow to have an object that's two pointers in size, when I worked in 3d gaming it wasn't with Vulkan, it was direct 3D and OpenGL and sometimes we would need to have pointers back to contexts or devices and it wasn't a major problem in big AAA titles. That said, it could be a major problem for you and you still might need another plan.

If benchmarks or other resource constraints show that the simple answer of putting an extra pointer on each of your buffer classes is inappropriate then I would considera single pointer that's static on your buffer class back to the device. That's problematic for a number of reasons, but does align closely with your needs. It has a lot of problems in common with singletons but solves the extra pointer per buffer if that's actually a problem.

The rule of avoiding singleton rules seems more about avoiding globals than avoiding objects there is only one instance of. Some problematic parts of singletons are that they can be accessed anywhere in the code, regardless of preconditions and that it reduces modularity as opposed to other ways to pass in dependencies. If the device pointer is only accessible as a private static member inside your buffer class then it mitigates some of these problems, but I can't tell you if it solves them for you. That's for you and your code base.

Some people argue that singletons are appropriate when there really only can be one of the thing. I don't hold a strong opinion on this point but their thought process is that if only one in memory resource can exist for one hardware resource then a singleton makes sense. This breaks down when you want to sub in a mock of that item for testing but has merits in other parts of code. And who's doing unit testing in video games anyway (/s)?

Right now I know of at least two other ways to structure this, but I don't want to go on too long. If you want to hear my thoughts, let me know and I'll bloviate endlessly.