Je ne peux pas être assez en désaccord avec l'esprit de la réponse acceptée. "Un outil de dernier recours"? Loin de là!
Selon moi, l'une des caractéristiques les plus fortes de C ++ par rapport à C et à d'autres langages similaires est la capacité d'exprimer des contraintes afin qu'elles puissent être vérifiées au moment de la compilation et qu'une mauvaise utilisation accidentelle puisse être évitée. Ainsi, lors de la conception d'une structure, demandez-vous quelles opérations elle devrait permettre. Toutes les autres utilisations doivent être interdites, et il est préférable que de telles restrictions puissent être implémentées statiquement (au moment de la compilation) afin qu'une mauvaise utilisation entraîne un échec de compilation.
Ainsi, lorsque l'on a besoin d'un tableau, les réponses aux questions suivantes spécifient son comportement: 1. Sa taille est-elle a) dynamique au moment de l'exécution, ou b) statique, mais uniquement connue au moment de l'exécution, ou c) statique et connue au moment de la compilation? 2. Le tableau peut-il être alloué sur la pile ou non?
Et sur la base des réponses, voici ce que je considère comme la meilleure structure de données pour un tel tableau:
Dynamic | Runtime static | Static
Stack std::vector unique_ptr<T[]> std::array
Heap std::vector unique_ptr<T[]> unique_ptr<std::array>
Oui, je pense unique_ptr<std::array>
devrait également être pris en considération, et ni l'un ni l'autre n'est un outil de dernier recours. Pensez simplement à ce qui correspond le mieux à votre algorithme.
Tous ces éléments sont compatibles avec les API C simples via le pointeur brut vers le tableau de données ( vector.data()
/ array.data()
/ uniquePtr.get()
).
PS En dehors des considérations ci-dessus, il y a aussi une propriété: std::array
et std::vector
ont une sémantique de valeur (ont un support natif pour la copie et le passage par valeur), alors unique_ptr<T[]>
qu'elles ne peuvent être déplacées (applique la propriété unique). Les deux peuvent être utiles dans différents scénarios. Au contraire, les tableaux statiques simples ( int[N]
) et les tableaux dynamiques simples ( new int[10]
) n'offrent ni l'un ni l'autre et doivent donc être évités si possible - ce qui devrait être possible dans la grande majorité des cas. Si cela ne suffisait pas, les tableaux dynamiques simples n'offrent également aucun moyen d'interroger leur taille - une opportunité supplémentaire pour les corruptions de mémoire et les failles de sécurité.
std::shared_ptr<T[]>
, mais il devrait y en avoir, et il le sera probablement en C ++ 14 si quelqu'un peut se donner la peine de rédiger une proposition. En attendant, il y en a toujoursboost::shared_array
.