How to use RAII appropriately/reduce memory leaks in this situation - c++

Question

I'm not sure how I can use RAII to my fullest in the situation that I have. This is the situation:
I am creating a basic renderer. Geometry is described by a Geometry class, which may have vertices added to it. In order for Geometry objects to be used for rendering, it must first be compiled (i.e. a VBO will be created for the Geometry). Compiliation (and decompiliation) of geometery objects is done via a Renderer object, decompilation must be done once you are done with geometery objects. If decompilation is not done, there will be memory leaks.
Here is an example of what I'm describing:
Renderer renderer; // the renderer object
{
Geometry geometry;
// add vertices
// and play around with material, etc.
if(!renderer.compile(geometery); // compile the geometery, so we can use it
{
cerr << "Failed to compile geometry!\n";
}
// now we can use it...
renderer.render(geometry, RenderType::TriangleStrips);
} // if I don't call renderer.decompile(geometry) here, I will get a leak
What I'm trying to do is decompile my geometery, without explicitly telling the renderer to decompile it. This is to simply reduce memory leaks. My first thought was to use RAII, but if I do so the Geometry class would require the Renderer class, which seems quite messy. As I would require a reference to the Renderer object which compiled the geometery.
Another alternative I thought of was to make the renderer create geometry, but this will cause geometry objects to allocated dynamically (i.e. with new), and it also seems quite messy.
I also thought of placing a handle object within the geometery, such as a unique_ptr to an abstract handle object.
e.g.
class GeometeryHandle
{
virtual ~GeometeryHandle() = 0;
};
Which might actually work, as it may also be used to store the GLuint within the handle. I am unsure if this is appropriate though, as I could simply decompile the geometry directly via a Renderer reference. i.e. it will do the same thing if I call it directly through the destructor.
How should I design this appropriately so I don't accidentally not decompile geometry?

Answer 1

It's not clear who is supposed to be responsible for what in your design. That's step 1 in figuring out how to employ any form of resource management: deciding who's responsible for what.
For example, you say that "Geometry is described by a Geometry class, which may have vertices added to it." OK, but how does this relate to the post-compilation data? If the user adds vertices to Geometry after it's compiled, do those vertices automatically get placed in the compiled data? Or is the compiled data completely separate from the Geometry class after compiling it, such that changes to the Geometry class don't update the compiled data?
It sounds to me like you're conflating two very different ideas: GeometryBuilder and Renderable. GeometryBuilder is what you put vertex data into. Then you take that and create a Renderable out of it. The Renderable is an optimized form of the data stored in a GeometryBuilder. The object is completely independent of the GeometryBuilder that created it. The Renderable is what you can actually render with.
So you would do this:
GeometryBuilder meshBuilder;
meshBuilder.AddVertex(...);
...
Renderable renderMesh = render.CreateRenderable(meshBuilder);
After this point, meshBuilder is independent of renderMesh. You can delete one and the other's fine. You can "compile" renderMesh multiple times and get identical copies of the same data. And so forth.

Answer 2

Method 1:
You can use a helper class:
class CompileHandler
{
private:
Geometry& g;
Renderer& r;
public:
CompileHandler(Geometry& _g, Renderer& _r) : g(_g), r(_r)
{
}
~CompileHandler()
{
r.decompile(g);
}
};
And you can use it the following way:
{
Geometry geometry;
CompileHandler ch(geometry,renderer);
// add vertices
// and play around with material, etc.
if(!renderer.compile(geometery); // compile the geometery, so we can use it
{
cerr << "Failed to compile geometry!\n";
}
// now we can use it...
renderer.render(geometry, RenderType::TriangleStrips);
// decompilation is automatic on destruction of the CompileHandler object
}
Method 2:
Create a more robust hierarchy:
GeometryCompiler
^
|
| inherits
|
Renderer
On compilation of the geometry, the geometry compiler (here, the renderer) notify the geometry that it has been compiled (and set a GeometryCompiler pointer inside the geometry to it, the compiler).
Then, on destruction of the geometry, if the pointer is not null, it can require the GeometryCompiler to decompile it.

Answer 3

RAII requires the "undo" operations to be played by dstructors.
In you case, the geometry is destroyed, but the render survive. The only trigger you have is the Geometry destructor, that should know what render compiled, to call him to decompile.
But since is not in the purpose of geometry to know about rederes, you most likely need an helper class (let's call it Compile_guard) that should be instantiated just after the geometry completion, taking a Geometry and Render as parameters, and calling Render::compile upon construction and Render::decompile upon destruction:
Renderer renderer; // the renderer object
{
Geometry geometry;
// add vertices
// and play around with material, etc.
Compile_guard guard(render, geometry);
if(!guard); // Invalid compilation ....
{
cerr << "Failed to compile geometry!\n";
return; // this is exception safe!
}
// now we can use it...
renderer.render(geometry, RenderType::TriangleStrips);
} //here guard will decompile
About the Compile_guard, it can be something like
class Compile_guard
{
public:
Compile_guard(Render& r, Geometry& g) :render(&r), geometry(&g), good(false)
{ good = render->compile(*geometry); }
~Compile_guard()
{ if(good) render->decompile(*geometry); }
explicit operator bool() const { return good; }
Compile_guard(const Compile_guard&) =delete; //just avoid copy and assign.
Compile_guard& operator=(const Compile_guard&) =delete;
private:
Render* render;
Geometry* geometry;
bool good;
};