C++ Adjacency List Representation of Graphs

Question

What is an efficient way to implement Adjacency List Representation of Graph in C++?

1. vector *edges;
2. list *edges;
3. map<int, int> *edges;
4. map<int, map<int, int>> edges;

In my opinion, it should be option 3 or 4, but I could not find any cons in using that... Are there any?

Can someone please help me, which will be the most efficient way of implementing the Adjacency List and also for Competitive Programming?

Answer 1

What is an efficient way to implement Adjacency List Representation of Graph in C++

Many typical graph problems apply to a given static graph that will need to be represented once whereafter the given representation can be re-used whilst solving the related problem. In this case, std::unordered_map<int, std::vector<int>> is an appropriate structure; where the value for a given key in the unordered map represents the (single-/bi-directional) connected vertices for a given vertex. There should be no reason to use the ordered std::map over the amortized constant-time lookup container std::unordered_map.

The associative containers std::unordered_map and std::unordered_set are quick for lookup (which you want here), but can have performance implications if they need to mutate often (e.g. for a dynamic graph problem). As always, profiling and measuring runtime and memory to find bottlenecks for you actual problem implementation is key if you are implementing a highperf computation program.

Answer 2

This is to especially address your fourth option.

You can take inspiration from Algorithms, 4th Edition by Sedgewick and Wayne and go with an array/vector of unordered_multisets (only neighbouring nodes in case of unweighted edges) or unordered_multimaps (neighbouring nodes and edges in case of weighted edges). In that book they use Java and work with the Bag data structure, which is an unordered collection of objects, with the possibility for duplicates.

The choice for the "outer" data structure could be an unordered_map also as suggested by @dfrib. As he says, one needs to measure for one's application to decide.