Rudimentary C++ Graph Implementation

Question

I am working on a graph implementation for a C++ class I am taking. This is what I came up with so far:

struct Edge {
    int weight;
    Vertex *endpoints[2]; // always will have 2 endpoints, since i'm making this undirected
};

struct Vertex {
    int data; // or id
    list<Edge*> edges;
};

class Graph {
public:
    // constructor, destructor, methods, etc.
private:
    list<Vertex> vertices;
};

It's a bit rough at the moment, but I guess I'm wondering... Am I missing something basic? It seems a bit too easy at the moment, and usually that means I'm designing it wrong.

My thought is that a graph is just a list of vertices, which has a list edges, which will have a list of edges, which has two vertex end points.

Other than some functions I'll put into the graph (like: shortest distance, size, add a vertex, etc), am I missing something in the basic implementation of these structs/classes?

"It seems a bit too easy at the moment, and usually that means I'm designing it wrong." I disagree. Especially as you are just designing a template class, the simpler the better. Do not forget addEdge(), addVertex(), etc. As you implement those, it may make you consider how your data is represented. — Kittsil, Dec 05 '16 at 09:57
Okay, that is a good point. On those two methods specifically, I can't add vertex without adding an edge (and vice versa), right? — Jeff, Dec 05 '16 at 13:59
I'm noticing that you seem to have to create all vertices first, then add the edges? — Jeff, Dec 05 '16 at 14:21
It depends. Usually no. You could make `addEdge()` check for the existence of a vertex and, if it doesn't exist, create it (of course, this only works if your vertices are closed under identity). — Kittsil, Dec 05 '16 at 20:28

score 1 · Answer 1 · answered Dec 04 '16 at 23:59

Sometimes you need to design stuff like this and it is not immediately apparent what the most useful implementation and data representation is (for example, is it better storing a collection of points, or a collection of edges, or both?), you'll run into this all the time.

You might find, for example, that your first constructor isn't something you'd actually want. It might be easier to have the Graph class create the Vertices rather than passing them in.

Rather than working within the class itself and playing a guessing game, take a step back and work on the client code first. For example, you'll want to create a Graph object, add some points, connect the points with edges somehow, etc.

The ordering of the calls you make from the client will come naturally, as will the parameters of the functions themselves. With this understanding of what the client will look like, you can start to implement the functions themselves, and it will be more apparent what the actual implementation should be

Okay, I guess you are right. I think my main question is about what a graph is? I've never made one. I will stub out the constructor to avoid confusion. In addition I haven't really thought of a real world example that I might use this for. — Jeff, Dec 05 '16 at 02:54

score 1 · Answer 2 · edited May 23 '17 at 12:13

Comments about your implementation:

A graph is a collection of objects in which some pairs of objects are related. Therefore, your current implementation is one potential way of doing it; you model the objects and the relationship between them.

The advantages of your current implementation are primarily constant lookup time along an edge and generalizability. Lookup time: if you want to access the nth neighbor of node k, that can be done in constant time. Generalizability: this represents almost any graph someone could think of, especially if you replace the data type of weight and data with an object (or a Template).

The disadvantages of your current implementation are that it will probably be slower than ideal. Looking across an edge will be cheap, but still take two hops instead of one (node->edge->node). Furthermore, using a list of edges is going to take you O(d) time to look up a specific edge, where d is the degree of the graph. (Your reliance on pointers also require that the graph fits in the memory of one computer; you'd have trouble with Facebook's graphs or the US road network. I doubt that parallel computing is a concern of yours at this point.)

Concerns when implementing a graph:

However, your question asks whether this is the best way. That's a difficult question, as several specific qualities of a graph come in to play.

Edge Information: If the way in which vertices are related doesn't matter (i.e., there is no weight or value to an edge), there is little point in using edge objects; this will only slow you down. Instead, each vertex can just keep a list of pointers to its neighbors, or a list of the IDs of its neighbors.

Construction: As you noticed in the comments, your current implementation requires that you have a vertex available before adding an edge. That is true in general. But you may want to create vertices on the fly as you add edges; this can make the construction look cleaner, but will take more time if the vertices have non-constant lookup time. If you know all vertices before construction the graph, it may be beneficial to explicitly create them first, then the edges.

Density: If the graph is sparse (i.e., the number of edges per vertex is approximately constant), then an adjacency list is again a good method. However, if it is dense, you can often get increased performance if you use an adjacency matrix. Every vertex holds a list of all other vertices in order, and so accessing any edge is a constant time operation.

Algorithm: What problems do you plan on solving on the graph? Several famous graph algorithms have different running times based on how the graph is represented.

Addendum:

Have a look at this question for many more comments that may help you out: Graph implementation C++

Rudimentary C++ Graph Implementation

2 Answers2