Discussion :

[darkman19320]

Bonjour tout le monde,

Je n'arrive pas � voir d'inconv�nient � utiliser le conteneur std::vector de la mani�re suivante:
std::vector<Object>

On peut modifier, supprimer, et lorsque le vecteur n'est plus utile (l'objet qui le contient est d�truit), les donn�es sont effac�es.

Est-ce que je loupe quelques choses?
Si oui, dans quelle situation est-il pr�f�rable de stocker les pointeurs? (A part bien s�r pour un gain d'espace dans le cas o� les m�mes objets Object doivent �tre stocker dans diff�rentes classes).

Merci d'avance.

[JolyLoic]

Le principal int�r�t : Si Object est une classe de base et que le vecteur doit stocker des instances de classes d�riv�es. (mais si les pointeurs poss�dent les objets point�s, un vector<[unique/shared]_ptr<Object> > est souvent une meilleure solution).

[Klaim]

Tout d�pends de ce qu'est Object.

D'abord il faut comprendre comment marche std::vector.

En gros, en interne, il va d�tenir une array (cr�e sur la heap) d'objets tous d'un m�me type.
Ce qui sous entends que si onfait grandir le vector de plus d'�l�ments qu'il ne peut contenir, il va devoir recr�er une auttre array plus grande, puis copier son ancienne array dedans et enfin d�sallouer l'ancienne array.

Donc, tout d�pends si Object peut
1. Etre contenu dans une array (de mani�re safe)
2. Peut �tre copi� (de mani�re safe)


Pour 1., il faut que ton objet ne soit pas polymorphique, c'est � dire que Object ne dois pas �tre une classe de base. Si tu comptes avoir des classes qui h�ritent de Object et que tu veux les contenir dans ton vector, alors tu ne peux pas faire std::vector<Object> puisqu'en interne tu auras une array d'Object qui n'auraient pas les informations des sous-classes (voir probl�me de "slicing").

Pour 2 il faut que Object soit copyable ou au moins constructible par copie.


Pour r�sumer:

1. Si Object est un type de base et que tu veux contenir tous les objets qui h�ritent de Object, utilise un "pointeur" (je vais y revenir).
2. Si Object est copyable et copy-constructible, alors tu peux utiliser std::vector<Object> (voir "s�mantique de valeur")
3. Si Object est gros et que tu fais grossir ton vector souvent, tu vas avoir des copies massives de temps en temps et donc potentiellement des ralentissements. A prendre en compte dans l'�quation.

Pour le cas ou tu as Object qui est une classe de base, alors tu dois utiliser un pointeur, mais pas forc�ment un pointeur "nu". Si tu utilises un pointeur nu, tu dois faire le code n�cessaire pour g�rer la vie des objets, et c'est assez relou parceque tu dois avoir un chemin clair pour d�finir quand doit mourrir ces Object.
Le moyen le plus simple c'est le passer par des smart pointers, qui sont justement des pointeurs (poru ceux de la STL) d�terminant la condition pour d�clencher la fin de vie d'un objet.

On a std::unique_ptr (si tu utilises un compilateur r�cent du moins) qui est � utiliser si celui qui a le std::unique_ptr<Object> doit �tre le seul � avoir le droit de vie et de mort sur l'objet point�.

Ensuite std::shared_ptr � utiliser quand tu veux que tous les objets qui pointent vers ton Ojbect le maintiennent en vie, mais si plus personne ne pointe dessus il est d�truit automatiquement.

Enfin std::weak_ptr est utiliser avec std::shared_ptr pour "briser les cycles" c'est � dire quand tu as des objets qui se pointent les uns les autres via des std::shared_ptr (ils font des cycles) et donc sont impossible a d�truire si on perds leurs r�f�rences.

Enfin bref dans ton cas alors le plus simple c'est de commencer par un std::vector< std::unique_ptr< Object > > si ton vecteur a le droit de vie et de mort sur ton Object, ou std::vector< std::shared_ptr< Object > > si le vecteur les maintiens en vie mais qu'a lext�rieur d'autres objets doivent pouvoir maintenir les Object en vie tant qu'il sont utilis�s meme si le vector est d�truit ou vid�.

Enfin si tu fais juste une liste de "r�f�rences" vers des objets, juste pour les "noter quelque part", alors un std::vector<Object*> est tout � fait correcte. Il faut juste faire attention � ce que l'on soit sur que les pointeurs soient toujours valides. Si il n'y a aucun moyen de s'en assurer, alors on est certainement dans un cas de std::shared_ptr, ou alors le design global n'est pas tres bon ou pas tr�s clair.

Voil� un topo global, mais en fait c'est une question qui d�pends �norm�ment du contexte, de la volont�e derri�re la contention, etc.

[gbdivers]

En compl�ment, pour la partie "copyable" et la s�mantique de valeur : FAQ C++ : Quand est-ce qu'une classe a une s�mantique de valeur ?

[darkman19320]

Merci beaucoup pour vos r�ponses ultra-rapides!

Je pense que je vais partir avec les shared_ptr (mais ceux de boost pour "pr�server" des performances similaires entre mes diff�rentes plateformes (Windows, Mac, Linux) ).