Persistent adjcacency graph index implementation - c++

Question

I have an object-based adjacency list graph that consists of nodes and edges stored in a vector.
class Graph
{
struct NodePrivate
{
QVector<int> m_FromEdges, m_ToEdges;
};
struct EdgePrivate
{
int m_iFrom, m_iFromIndex, m_iTo, m_iToIndex;
};
//...
private:
QVector<NodePrivate> m_Nodes;
QVector<EdgePrivate> m_Edges;
};
In order to ensure contiguity (and constant speed) of the graph elements when removing them I do removals by swapping the last element with the one to be removed.
Now when user of the graph accesses the elements he does so via Node and Edge classes that are really just a wrapper around an index to the graph (and int).
class Item
{
//...
private:
int m_Index = -1; //or QSharedPointer<int>, see below
const Graph *m_Graph = nullptr;
};
class Node : public Item {};
class Edge : public Item {};
By removing a node or an edge these indexes might become invalid. I would like these to be persistent and insofar have tried (successfuly) two strategies but I do not like either of them very much:
1) Track all objects of type Node and Edge by registering them and deregistering them in constructor(s) and destructor respectively. These are then used to update the internal index whenever the relevant index changes. Biggest drawback of this is quite a lot of unnecessary registered temporaries.
2) The other option is to use smart-pointer approach by having the index dynamic (std::shared_ptr<int>). The index is then updated through that which is arguably better than updating all objects but at the cost of dynamic memory.
Is there any other option to implement this or improve upon these two designs?

Answer 1

First of all, I must admit that I don't think this problem can be solved perfectly. If you really want to make a lot of small changes to your graphs regularly, then you should switch to storing everything in linked lists instead of arrays. Also, you can just give up and say explicitly, that all Node and Edge handles are invalidated, just like std::vector::iterator-s are invalidated when you add an element to std::vector.
General discussion
In your case, vertices and adjacency lists are stored in arrays. Also, you have Node and Edge helpers, which allow user to point to the real nodes and edges whenever they want. I'll call them handles (they are like C++ iterators without any iteration capabilities). I see two different ways for maintaining the handles after changes.
The first way is to store direct pointer (or index) to a physical object in each handle, as you do it now. In this case you have to change all handles to an object, whenever the object is moved. That is why you absolutely must register all the handles you give away somewhere. This is exactly the first solution you suggest, and it leads to "heavy" handles: creating, deleting and copying handles becomes costly, regardless of whether any objects are actually moved.
The second way is to store pointer to some intermediate thing inside a Handle. Then make sure that this thing is never changed during object's lifetime, even if objects move. Clearly, the thing you point to in a handle must be something different from real physical index of your node of edge, since they change. In this approach you have to pay for indirect access each time a handle is dereferenced, so handle access becomes slightly heavier.
The second solution you propose is following this second approach. The intermediate things (which are being pointed to by your handles) are dynamically allocated int-s wrapped in shared_ptr, one never-moving int per object. You have to suffer at least from separate dynamic allocation (+deallocation) per each object created, also from reference counters updates. The reference counters can be easily removed: store unique_ptr-s in NodePrivate and EdgePrivate objects, and raw pointers in Node and Edge objects.
New approach
The other solution following the second approach is to use IDs as intermediate things pointed to be handles. Whenever you create a node, assign it a new node ID, same for edges. Assign IDs sequentally, starting from zero. Now you can maintain bidirectional correspondence between physical indices and these IDs, and update it in O(1) time on a change.
struct NodePrivate
{
QVector<int> m_FromEdges, m_ToEdges;
int id; //getting ID by physical index
};
struct EdgePrivate
{
int m_iFrom, m_iFromIndex, m_iTo, m_iToIndex;
int id; //getting ID by physical index
};
private:
QVector<NodePrivate> m_Nodes;
QVector<EdgePrivate> m_Edges;
QVector<int> m_NodeById; //getting physical index by ID
QVector<int> m_EdgeById; //getting physical index by ID
Note that these new m_NodeById and m_EdgeById vectors grow when objects are created, but do not shrink when objects are deleted. So you'll have empty cells in these arrays, which will only be deallocated when you delete your graph. So you can use this solution only if you are sure that the total amount of nodes and edges created during graph's lifetime is relatively small, since you take 4 bytes of memory per each such object.
Improving memory consumption
You might have already noticed the similarity between the new solution just presented and the shared_ptr-based solution you had. In fact, if we do not distinguish C pointers and array indices, then they are the same, except for: in your solution int-s are allocated in heap, but in the proposed solution int-s are allocated in a pool allocator.
A very well-known improvement to a no-free pool allocator is the technique known as 'free lists', and we can apply it to the solution described above. Instead of always assigning new IDs to created objects, we allow to reuse them. In order to achieve that, we store a stack of free IDs, When an object is removed, we add its ID to this stack. When a new object is created, we take an ID for it from the stack. If stack is empty, then we assign a new ID.
struct EdgePrivate
{
int m_iFrom, m_iFromIndex, m_iTo, m_iToIndex;
int id; //getting ID by physical index
};
private:
QVector<EdgePrivate> m_Edges;
QVector<int> m_EdgeById; //getting physical index by ID
QVector<int> m_FreeEdgeIds; //freelist: stack of IDs to be reused
This improvement makes sure that memory consumption is proportional of the maximum number of objects you ever had alive simultaneously (not the total number objects created). But of course it increases memory overhead per object even further. It saves you from malloc/free cost, but you can have issues with memory fragmentation for large graphs after many operations.