[mreiland]

I'm not a game developer, but I experienced something similar to that when playing around with SFML. Their texture objects adhere to RIAA, so copy constructors will copy the texture from GPU memory to main memory, copy it to another location in main memory, re-upload it to GPU memory, then destroy the original texture and the memory it took up when copying to main memory.

I asked about it and the response I got was basically "It's RIAA, that's how you do C++". The worst part is they have a caching system underneath that tracks OGL handles across different objects, and it's even safe for access by threads.

But whoever designed their texture class chose not to use it.

So when I read your description I understand where you're coming from a bit. I'm not sure I understand why you couldn't just avoid using destructors, but I've honestly never tried to use a C++ allocator for anything as I've never needed control quite that tight for anything I do.

[yoklov]

Well, you can avoid using desctructors, but then you can't use the majority of the STL, so what's the point? (This is basically what I do anyway)

[mreiland]

You don't have to tie resource lifetime to object lifetime, that's the mistake the SFML folks made.

[yoklov]

Right, my point is that I typically don't really want to tie memory lifetime to object lifetime either. So the whole of RAII is not a great fit, outside of a couple edge cases.

[mreiland]

RAII is about resources, not memory. If you don't want to tie memory lifetime to object lifetime then don't. That's the entire point of things like smart pointers.

That's exactly the issue SFML had. This idea that RAII implies tying resources directly to an objects lifetime. It doesn't.