Discussion :

[Invité]

Bonsoir à tous.
Je suis bien conscient que 3 questions dans un même sujet n'est peut-être pas une chose très bien à faire. Mais étant donné que ces questions sont relativement fermées et toutes en rapport avec les vectors, je me permet...


D'après votre exemple d'utilisation des vectors dans la FAQ C++, la déclaration

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::vector<Symbole> symboles;

devrait créer un vector de Symbole vide du nom de symboles.
Maintenant supposons que l'on programme une classe TableSymboles dont l'unique attribut sera le vector déclaré ci-dessus. Si cette même déclaration est écrite dans TableSymboles.h.
Est-il nécessaire de faire quelque chose dans le constructeur si le vector est déjà créé :



Supposons maintenant que de la Symbole dérivent plusieurs autres classes (Derive1, Derive2) qui contiennent plus d'attributs que Symbole et donc nécessitent plus de place mémoire.
Est-il possible de conserver la déclaration de vector ci-dessus, ou bien est-ce que lors de l'ajout d'une instance de Derive2 au vector, il n'y aura pas la place nécessaire pour recevoir l'instance de Derive2 complètement :



Dernière question moins théorique.
J'ai commencé à coder en supposant qu'il ne fallait rien faire dans le constructeur de ma classe TableSymboles et que l'ajout d'une instance de classe dérivé de Symbole dans un vecteur de Symbole ne posait pas de problème.
Lors de la compilation d'un TableSymboles.cpp comprenant seulement le constructeur, j'obtiens ceci:

/usr/bin/ld: Undefined symbols:
_main
Symbole::~Symbole()
collect2: ld returned 1 exit status

Or j'ai bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include "TableSymboles.h"

dans TableSymboles.cpp et j'ai bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include "Symbole.h"

dans TableSymboles.h.
Enfin le destructeur de Symbole est déclaré comme ceci dans Symbole.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  //Destructeur
  ~Symbole();

(et son implémentation est vide dans le .cpp associé puisque Symbole ne créer rien dynamiquement en mémoire)

Je suppose que lorsqu'on créer un vector d'objets, la stl a été faite de façon à vérifier que ces objets ont bien des constructeurs et destructeurs qui seront appelés lors de l'ajout ou de la suppression d'un objet dans le vecteur.
Mais pourquoi g++ ne trouve-t-il pas mon destructeur :


Oulà! J'espère que je n'ai pas été trop long... J'ai bien essayé de m'informer avec la doc "officielle" de la STL, mais ça ne m'a pas vraiment aidé

Merci d'avance pour votre aide

[Fiquet]

Hello,

1/ Si tu déclares ton tableau de la même manière que tu l'a faite ici, non tu n'as rien d'autre à ajouter pour déclarer le vecteur. Le problème viendrait si tu stockes des données dynamiques, il viendrait à toi le travail d'allouer la mémoire pour tes données et de la détruire.

Dans cet exemple précis la question serait plutôt l'utilité de faire une classe TableSymboles avec un membre unique. Je ne pense pas que ça serve à grand chose, tu pourrais directement déclarer ton vecteur au milieu du code.

2/ Dans ce cas là, pour déclarer un vecteur de dérivé (ex. Derive1) il faudra écrire ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::vector<Derive1> symboleDerive;

sinon tu ne pourras pas mettre un Derive1 dans un vecteur de Symbole. Le compilateur te donneras une erreur. Ce que tu cherches à faire ressemble au polymorphisme. Dans ce cas il faudra créer un vecteur de pointeurs de Symbole. (Plus d'infos ICI ).

3/ As-tu quand même défini le corps de la fonction, même si l'implémentation est vide ? Tu peux y remédier en définissant ton destructeur comme ceci dans ton code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

~Symbole() {}     // Destructeur vide

J'espère que ça t'aideras

[reggae]

Est-il nécessaire de faire quelque chose dans le constructeur si le vector est déjà créé?

Si tu veux tu peux l'unitialiser dans le constructeur mais ce n'est pas obligatoire.

[Luc Hermitte]

2/ Il est impossible d'utiliser les conteneurs standard sur des références. Il faut, ici, que cela soit sur des pointeurs obligatoirement -- en supposant qu'il y ait un sens, ici, à faire un vecteur de fruits qui mélange bananes et poires. Ne pas oublier le destructeur virtuel, ainsi que les fonctions membre virtuelles qui donneront un sens à avoir un vecteur de types parents.

[Fiquet]

2/ Il est impossible d'utiliser les conteneurs standard sur des références.

J'ai corrigé mon erreur . Mais je ne savais pas que ce n'était pas possible ? Je ne comprends pas la raison à celà.

PS: Je croyais avoir vu celà sur des conteneurs MFC, mais en fait après vérification ce qu'il est possible de faire avec un conteneur MFC c'est de spécifier le type de passage dans les arguments de fonctions comme ceci par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CList<Object, Object&> List;

est-il possible de faire ceci avec les conteneurs de la STL?

Merci d'avance pour les précisions .

[Laurent Gomila]

Mais je ne savais pas que ce n'était pas possible ? Je ne comprends pas la raison à celà.

Une référence n'est qu'un alias, elle n'a pas de représentation physique propre. Il s'agit juste d'un raccourci syntaxique fourni par le langage pour manipuler des objets, sans passer par des pointeurs. Donc tu ne peux bien sûr pas stocker des références dans un conteneur.

est-il possible de faire ceci avec les conteneurs de la STL?

Non, dans ce contexte le passage de paramètre se fait obligatoirement par référence constante (personnellement je ne vois pas trop l'intérêt d'avoir ajouté ce choix au niveau des conteneurs des MFC).

[Invité]

Je vous remercie pour vos lumières.

Je suis donc passé par un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::vector<Symbole*> symboles;

et j'ai déclaré le destructeur de Symbole virtuel. Ce qui a réglé pas mal de problèmes déjà.

Je commence à me familiariser avec les iterator maintenant...

Encore merci!

[reggae]

Je commence à me familiariser avec les iterator maintenant... Confused

C'est bien parce que tu en auras besoin! Par contre pour te simplifier la vie de temps en temps tu peux utiliser des pointeurs à la place des itérateurs.

[Luc Hermitte]

.. un pointeur est aussi un itérateur (à accès direct)

[JolyLoic]

PS: Je croyais avoir vu celà sur des conteneurs MFC, mais en fait après vérification ce qu'il est possible de faire avec un conteneur MFC c'est de spécifier le type de passage dans les arguments de fonctions comme ceci par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CList<Object, Object&> List;

est-il possible de faire ceci avec les conteneurs de la STL?

L'idée de la chose est qu'il y a certains types qu'il est plus simple de passer par valeur que par référence. Et donc on spécifie comment on souhaite faire.

Mon avis là dessus :
- Je pense que les compileteurs ont du prendre en compte correctement le passage par référence de façon à ce que void f(int const &i) ne coûte pas plus cher que void f(int i). Il ne faut faut pas oublier que les MFC sont très vieilles (tiens, ça date de quand déjà ?), et qu'à l'époque, les références devaient être un truc encore un peu neuf.

- Si vraiment ce genre de chose compte, on ne le traiterait plus ainsi. On associerait un trait au type. Voir par exemple http://www.boost.org/doc/html/boost_typetraits.html