Cette réponse ne concerne pas uniquement le C ++ puisque tout ce qui est mentionné concerne les structures de données elles-mêmes, quel que soit le langage. Et ma réponse suppose que vous connaissez la structure de base des listes et des matrices de contiguïté.
Mémoire
Si la mémoire est votre principale préoccupation, vous pouvez suivre cette formule pour un graphique simple qui autorise les boucles:
Une matrice d'adjacence occupe n deux / 8 Surface d'octets (un bit par entrée).
Une liste de contiguïté occupe 8e espace, où e est le nombre d'arêtes (ordinateur 32 bits).
Si nous définissons la densité du graphe comme d = e / n 2 (nombre d'arêtes divisé par le nombre maximum d'arêtes), nous pouvons trouver le "point d'arrêt" où une liste prend plus de mémoire qu'une matrice:
8e> n deux / 8 quand d> 1/64
Donc, avec ces nombres (toujours spécifiques à 32 bits), le point d'arrêt arrive à 1/64 . Si la densité (e / n 2 ) est supérieure à 1/64, une matrice est préférable si vous souhaitez économiser de la mémoire.
Vous pouvez lire à ce sujet sur wikipedia (article sur les matrices de contiguïté) et sur de nombreux autres sites.
Note d'accompagnement : on peut améliorer l'efficacité spatiale de la matrice de contiguïté en utilisant une table de hachage où les clés sont des paires de sommets (non dirigées uniquement).
Itération et recherche
Les listes de contiguïté sont un moyen compact de représenter uniquement les arêtes existantes. Cependant, cela se fait au prix d'une recherche éventuellement lente d'arêtes spécifiques. Etant donné que chaque liste est aussi longue que le degré d'un sommet, le temps de recherche le plus défavorable pour vérifier une arête spécifique peut devenir O (n), si la liste n'est pas ordonnée. Cependant, rechercher les voisins d'un sommet devient trivial, et pour un graphe clairsemé ou petit, le coût de l'itération à travers les listes de contiguïté peut être négligeable.
Les matrices d'adjacence, quant à elles, utilisent plus d'espace afin de fournir un temps de recherche constant. Puisque toutes les entrées possibles existent, vous pouvez vérifier l'existence d'une arête en temps constant à l'aide d'index. Cependant, la recherche de voisins prend O (n) car vous devez vérifier tous les voisins possibles. L'inconvénient évident de l'espace est que pour les graphes clairsemés, beaucoup de remplissage est ajouté. Voir la discussion sur la mémoire ci-dessus pour plus d'informations à ce sujet.
Si vous ne savez toujours pas quoi utiliser : la plupart des problèmes du monde réel produisent des graphiques clairsemés et / ou volumineux, qui conviennent mieux aux représentations de listes de contiguïté. Ils peuvent sembler plus difficiles à implémenter, mais je vous assure qu'ils ne le sont pas, et lorsque vous écrivez un BFS ou un DFS et que vous voulez récupérer tous les voisins d'un nœud, ils ne sont qu'à une ligne de code. Cependant, notez que je ne fais pas la promotion des listes de contiguïté en général.