Search code examples
c++pointersraii

Do optional elements break RAII and if yes what is a better approach?


I have a 2-dimensional matrix of cells. Usually only invisible algorithms work with these cells. But sometimes I want to visualize each cell so I added a pointer to a graphical object

class Cell
{
   ...
   QAbstractGraphicsItem* representation_;
   ...
}

The constructor of Cell sets representation_ to 0. Sometimes another Visualization class iterates on the matrix and adds elements to Cells that visualize the content of each cell by colors.

I think this breaks the RAII paradigma. Do you have a better approach?

I could create another 2-dimensional matrix and from there link to the original matrix so that the pointers are on the visualization side but I would need two matrices then.


Solution

  • RAII is misnamed, as (I think) Scott Meyers points out.

    It shouldn't be called "Resource Acquisition is Initialization", it should be called "Destruction is Resource Release". But we are where we are.

    If the Cell "owns" the object pointed to by representation_, and deletes it in its destructor, then this is still a form of RAII, the same way that you can initialize a shared_ptr with a null pointer, then later set it to something else. I assume you use it correctly (ensure that the object is saved to some Cell or other immediately after it is created, with no chance of failure between the completion of the constructor and the storing of the pointer somewhere it will be eventually freed). If so, you're using the important part of RAII, even though it's not a constructor doing the work.

    It's probably a violation of the single responsibility principle. You've made Cell responsible for representing a cell, and also for memory-managing this QAbstractGraphicsItem object. It would probably simplify things to change representation_ to a smart pointer type, so there's no need for any special code in the destructor of Cell.

    If the Cell doesn't "own" the object pointed to by representation_, then that doesn't inherently violate RAII either, it just doesn't implement it. Something else will have to be responsible for ownership of the object. Maybe that other thing uses RAII, maybe it violates it. For the thing to ensure the object lives as long as the Cell needs it, it would have to be involved somehow in the lifecycle of the Cell (for instance, if it owns the cell then you might be fine). So if it isn't, there's a good chance it's violating RAII somehow.