Petit problème de vector

Version imprimable

Bonsoir,

Alors, depuis hier, j'ai fait un sous-moteur à la lib SFML.
Sauf que je voudrais utiliser une liste (array sans limite) de type DrawUnit, qui est une class contenant une fonction drawOnTheWindow pour le moment.
Et j'ai une belle erreur de la part de Visual ... Donc si quelqu'un peux m'éclairer
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 #ifndef DEF_DRAWCLASS #define DEF_DRAWCLASS #include <SFML/Graphics.hpp> #include <vector> #include "DrawUnit.h" using namespace sf; class DrawClass { private: std::vector<DrawUnit*> liste_to_draw; public: DrawClass(); ~DrawClass(); void drawAll(RenderWindow* window); int add_elem(DrawUnit* toAdd); void remove_elem(int index); }; #endif
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 #include "DrawClass.h" DrawClass::DrawClass() { } DrawClass::~DrawClass() { } void DrawClass::drawAll(RenderWindow* window) { int i = 0; for (i = 0; i < (int)liste_to_draw.capacity(); i++) { liste_to_draw[i]->drawOnTheWindow();//Erreur ici } } int DrawClass::add_elem(DrawUnit* toAdd) { liste_to_draw.push_back(toAdd); return liste_to_draw.end() - liste_to_draw.begin(); } void DrawClass::remove_elem(int index) { liste_to_draw.erase(liste_to_draw.begin() + index); }
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #ifndef DEF_DRAWUNIT #define DEF_DRAWUNIT #include <SFML/Graphics.hpp> using namespace sf; class DrawUnit { private: public : int drawOnTheWindow();//RenderWindow* window); }; #endif
Code:

1 2 3 4 5 6 7 8 #include "DrawUnit.h" int drawOnTheWindow()//(RenderWindow* window) { //window->clear(); return 0; }
L'erreur :

Code:

Error 1 error LNK2019: unresolved external symbol "public: int __thiscall DrawUnit::drawOnTheWindow(void)" (?drawOnTheWindow@DrawUnit@@QAEHXZ) referenced in function "public: void __thiscall DrawClass::drawAll(class sf::RenderWindow *)" (?drawAll@DrawClass@@QAEXPAVRenderWindow@sf@@@Z) C:\Users\Nico\Documents\Visual Studio 2010\Projects\SFML\SFML\DrawClass.obj SFML

ps : ça serais simpa aussi de dire s'il y a des trucs fais "bizarrement" car je passe du vb.net au C++, ça change ..

Merci :)

13/05/2013, 20h37
koala01
Salut,

L'erreur te dit que l'éditeur de liens ne trouve pas le code binaire correspondant à DrawUnit::drawOnTheWindow().

Selon moi, il y a trois solutions:
1. Soit VisualStudio s'est "emmêlé les pinceaux" et n'a pas recompilé DrawUnit.cpp après que tu aies changé le prototype de drawOnTheWindow
2. Soit tu as modifié le prototype de drawOnTheWindow dans le DrawUnit.h mais pas dans DrawUnit.cpp
3. Soit, enfin, DrawUnit.cpp ne fait pas partie du projet
Dans le premier cas, je te conseillerais de faire un "clear" de ton projet et de tout recompiler

Dans le deuxième cas, il faut corriger soit DrawUnit.h soit DrawUnit.cpp pour que les prototypes correspondent (et de préférence faire un clear du projet avant de tout recompiler :D)

Dans le troisième cas, il faut veiller à rajouter le fichier manquant à ton projet, avant de compiler à nouveau

Enfin, si tu es face à un projet important qui serait subdivisé en plusieurs "sous projet" et que DrawUnit.h / DrawUnit.cpp font partie d'un sous projet particulier, il serait bon de commencer par faire pareil avec le sous projet en question ;)
13/05/2013, 21h36
Nicogo

Okk, Merci.

J'essaye tout ça demain et je vous redis quoi.

édit :

Et sinon le code reste "propre" ?
13/05/2013, 21h45
koala01
Ouppsss...

En relisant le code, je viens de trouver l'erreur...

Tu as défini
Code:

1 2 3 4 5 int drawOnTheWindow()//(RenderWindow* window) { //window->clear(); return 0; }
qui défini une fonction libre nommée DrawOnTheWindow...

Or, tu déclare une fonction membre de la classe DrawUnit qui porte ce nom.

comme je présumes que tu souhaites effectivement qu'il s'agisse d'une fonction membre de ta classe, la définition devrait être pleinement qualifiée:
Code:

1 2 3 4 5 int DrawUnit::drawOnTheWindow()//(RenderWindow* window) { //window->clear(); return 0; }
Citation:

Envoyé par Nicogo

Okk, Merci.

Et sinon le code reste "propre" ?

Ben, à moins que la durée de vie de tes objet de type DrawUnit ne soit "gérée par ailleurs", tu risque d'avoir une belle fuite mémoire lors de la destruction de ton objet de type DrawClass.

Ce que tu places dans ta liste, c'est des pointeurs, qui correspondront de toutes évidences à des objets pour lesquels tu as eu recours à l'allocation dynamique.

Tu as donc accepté "de facto" de prendre seul la responsabilité de déterminer quand ces objets seront détruits.

Lorsque la liste sera détruite, tu perdra "toute référence" vers les objets qu'elle contient, et tu ne pourras donc plus y accéder pour détruire correctement les éléments pointés.

Je te laisses le soin de réfléchir à la manière de résoudre ce problème ;)
13/05/2013, 21h57
Kalith
Citation:

Envoyé par Nicogo

Et sinon le code reste "propre" ?

Non, tu as un bug ici :
Code:

1 2 3 4 5 6 7 8 9 void DrawClass::drawAll(RenderWindow* window) { int i = 0; for (i = 0; i < (int)liste_to_draw.capacity(); i++) { liste_to_draw[i]->drawOnTheWindow();//Erreur ici } }
std::vector::capacity() te donne le nombre maximum d'éléments que peux contenir ton std::vector avant qu'il ait besoin de ré-allouer de la mémoire. Toi tu veux plutôt le nombre total d'éléments qui sont stockés, et pour ça il faut utiliser std::vector::size().

Petite remarque en passant sur la boucle, tu peux écrire plus simplement :

Code:

for (int i = 0; i < (int)liste_to_draw.size(); i++)

Mais il est plus correct d'utiliser une variable non signée pour l'itération, en particulier std::size_t. D'une part ça t'évite le warning que Visual doit t'envoyer parce que tu compares une grandeur signée i et une grandeur non signée std::vector::capacity(), et d'autre part c'est plus correct car i n'a aucune raison d'être négatif :

Code:

for (std::size_t i = 0; i < liste_to_draw.size(); i++)

Sinon tu peux utiliser les itérateurs. La notation est un peu lourde, mais parfois plus pratique car la majorité des méthodes de std::vector (ou encore certaines fonctions de la bibliothèque standard) travaillent sur des itérateurs. Ici ça n'a pratiquement aucun intérêt, si ce n'est qu'il est un peu plus difficile d'écrire une sottise :
Code:

1 2 3 4 for (std::vector<DrawUnit*>::iterator i = list_to_draw.begin(); i != list_to_draw.end(); ++i) { (*i)->drawOnTheWindow(); }
Et le top du top, si tu peux utiliser le C++11 :
Code:

1 2 3 4 for (DrawUnit* unit : list_to_draw) { unit->drawOnTheWindow(); }
14/05/2013, 14h31
r0d

Bonjour,

au cas où tu cherches à améliorer ton code, tu devrais remplacer tous tes pointeurs par des références (références constantes dans certains cas). En tout cas, sur le code que tu as posté, je ne vois pas l'utilité des pointeurs, or, comme on dit: "les pointeurs, on ne les utilise que quand on ne peut pas s'en passer".
14/05/2013, 14h47
darkman19320

Bonjour,

Juste une petite remarque, évite d'utiliser "using namespace" dans les fichiers d'entête, ça pourrais poser problème dans d'autres projets.
14/05/2013, 16h33
Nicogo

Okk, j'ai tout lu.
Et je vais tout améliorer, déjà les références.
Ensuite, oui j'avais oublier le "UnitDraw::" ... Pas l'habitude des class en C++ :(
Et pour se qui est des destructeurs, je vais voir.
Si j'ai besoin d'aide je vous rappel.

Sur ce, MERCI à tous :)
14/05/2013, 17h57
Nicogo

Citation:

Envoyé par r0d

Bonjour,

au cas où tu cherches à améliorer ton code, tu devrais remplacer tous tes pointeurs par des références (références constantes dans certains cas). En tout cas, sur le code que tu as posté, je ne vois pas l'utilité des pointeurs, or, comme on dit: "les pointeurs, on ne les utilise que quand on ne peut pas s'en passer".

Déso du double post, mais par curiosité, dans quel(s) cas est-on obliger d'utiliser un pointeur ?
14/05/2013, 19h18
koala01
Citation:

Envoyé par Nicogo

Déso du double post, mais par curiosité, dans quel(s) cas est-on obliger d'utiliser un pointeur ?

A vrai dire la différence majeure (en dehors de la syntaxe pour accéder aux différents membres) qui existe entre les pointeurs et les références, c'est que les références ont une garantie "de non nullité", d'existence de l'objet référencé.

Si tu es sur que l'objet référencé (pointé) par une référence (un pointeur) existera à chaque fois que tu auras recours à la référence (ou au pointeur), tu as tout intérêt à utiliser une référence : cela te fera toujours une vérification (de non nullité) en moins à mettre en place.

Le premier cas dans lequel tu n'as pas le choix et que tu dois utiliser un pointeur est le cas où un objet (une variable, un membre ou un argument) peut ne pas exister.

Attention, je dis bien que l'objet peut ne pas exister!, et non que l'objet peut être dans un état considéré comme invalide (une chaine de caractères vides, par exemple).

Typiquement, c'est le genre de relation parent<-->enfant frère ou <--> soeur: un "parent" n'a pas forcément d'enfant, un enfant n'a pas forcément de parent (ca peut être la "racine de l'arbre") un enfant peut ne pas avoir de frère (ou de soeur).

Dans ce cas, on ne peut pas se contenter de mettre le parent, l'enfant ou le frère(la soeur) dans un état invalide, parce qu'il (elle) imposerait d'avoir un autre parent (enfant, frère ou soeur) qui serait lui aussi dans un état invalide, et cela "ad vitam".

Il faut pouvoir clairement indiquer qu'il n'y a purement et simplement pas de parent (ou d'enfant ou de frère ou de soeur).

A ce moment là, nous utiliserons un pointeur dont nous mettrons la valeur à NULL (nullptr en C++11) qui est la seule valeur connue pour être une adresse mémoire invalide.

Les autres cas ont trait à l'héritage et au polymorphisme:

Tu ne peux profiter du polymorphisme qu'avec des pointeurs ou des références.

Mais il est totalement impossible de placer une référence dans une collection: on ne peut y placer que des objets ou des pointeurs.

Si tu as une classe de base "FormeGéométrique" dont dérivent des classes "Carré", "Rectangle", "Triangle", "Losange", "Cercle", ... et que tu veux pouvoir créer une collection de forme géométriques (sans plus de précision) en profitant du polymorphisme, en y mettant des carrés, des rectangles, des losange ou n'importe quelle autre forme géométrique, tu n'auras pas le choix:

Tu devras créer une collection de "pointeur sur FormeGéométrique".

Cela ressemblerait donc à quelque chose comme std::vector<FormeGeometrique*>.

Mais, encore une fois, une fois que tu a la certitude qu'un élément particulier de ton vecteur existe, rien ne t'empêche (bien au contraire: tout devrait t'inciter à le faire :D) de déréférencer le pointeur afin de passer une référence à une fonction, sous une forme qui pourrait être proche de
Code:

1 2 3 4 5 std::vector<FormeGeometrique *> tab; /* il est rempli, d'une manière ou d'une autre */ for(size_t i = 0; i< tab.size(); ++i){ laFonctionQuiAttendUneReferenceSurFormeGeometrique(*tab[i]); }
;)
14/05/2013, 19h30
PilloBuenaGente

Citation:

Les autres cas ont trait à l'héritage et au polymorphisme:

Tu ne peux profiter du polymorphisme qu'avec des pointeurs ou des références.

Mais il est totalement impossible de placer une référence dans une collection: on ne peut y placer que des objets ou des pointeurs.

Bonjour,

ne serait il pas possible d'utiliser le conteneur "map", qui, depuis c++11, peut contenir des références ?!
Merci !
14/05/2013, 20h17
koala01
Citation:

Envoyé par PilloBuenaGente

Bonjour,

ne serait il pas possible d'utiliser le conteneur "map", qui, depuis c++11, peut contenir des références ?!
Merci !

Hummm...
1. Cela dépend énormément de l'utilisation que tu veux faire de ta collection, et std::map a la particularité de trier les éléments selon une clé
2. Je serais vraiment surpris que std::map puisse contenir des références: tous les conteneurs peuvent utiliser la sémantique de mouvement, mais cela n'a rien à voir avec l'utilisation de références ;)
3. Même en utilisant la sémantique de mouvement, tu retombes dans le problème que la valeur est un objet et non une référence ou un pointeur... Adieux l'utilisation du polymorphisme
4. Avec une référence, tu restes soumis au problème de la durée de vie de l'objet référencé. Pour pouvoir utiliser des références, il faudrait donc t'assurer que chaque objet référencé
  1. ait une durée de vie au moins égale à celle de ta map (ou de n'importe quel autre conteneur)
  2. que l'adresse de l'objet ne change pas
  ce qui t'obligerait à avoir un conteneur par type dérivé particulier (et ca ne pourrait pas être un std::vector!!!), sans oublier le fait que les classes ayant sémantique d'entité sont typiquement non copiables et non assignables.
En résumé : quand bien meme il y aurait une collection qui soit en mesure de contenir des références sur des objets (ce dont je doute très fortement), cela te compliquerait énormément la vie de l'utiliser au vu de ce qu'il faudrait faire "sur le coté" afin d'assurer l'existence des objets contenus
14/05/2013, 21h47
PilloBuenaGente

Bah ça parait évident maintenant... :ccool:, c'est un truc qui me travaillait, je ne sait plus ou j'ai vu cette définition:

Code:

std::map< const int, Foo& > map;

Mais elle ne devait servir qu'a représenter un contexte... Fichtre l'anglais est important :mouarf:

Elle ne faisait pas grogner mon compilateur non plus, j'ai donc gardé le doute. Tout va mieux !

En fait, il faut comprendre que les références ont un comportement strictement similaire (en terme de code binaire généré) aux pointeurs et qu'une même erreur aura strictement les mêmes effets.

Ainsi, l'utilisation d'une référence pour laquelle l'objet référencé a été détruit aura strictement le même effet que l'utilisation d'un pointeur sur lequel on a appelé delete (ou delete[]) sans penser à le mettre à NULL (ou nullptr en c++11) (ou pour lequel on n'aura pas pris soin de vérifier s'il est à NULL): cela provoquera un undefined behaviour (généralement une erreur de segmentation).

Le fait qu'une référence doive être initialisée au moment de sa déclaration permet (du fait de l'ordre de destruction des variables temporaires) d'éviter les problèmes dans la plupart des cas, parce que cela oblige à avoir... un objet existant pour initialiser la référence, sauf

1- Si l'on essaye de renvoyer une référence sur une variable temporaire au sortir d'une fonction:
Code:

1 2 3 4 5 Untype & foo(){ Untype data; /* ...*/ return UnType; }
(ce code devrait normalement lancer un avertissement ;) )

2- si (pour autant qu'il soit possible de le faire) on venait à essayer de placer la référence dans une collection de référence:

Il est en effet impossible de garantir que la durée de vie de la collection de référence est bel et bien inférieure à celle de tous les objets qu'elle devrait contenir.

Et quand bien même ce serait possible, cela signifierait qu'un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 void foo(){ UnType a; UnType b; UnType c; UnType d; UnType e; if(condition){ Collection<UnType &> col; /* ajout de a, b, c, d et e à col puis utilisation de col*/ } }
serait valide et "sécure" alors qu'un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 void foo(){ Collection<UnType &> col; if(condition){ UnType a; UnType b; UnType c; UnType d; UnType e; /* ajout de a, b, c, d et e à col */ } /* utilisation des élément de col */ }
mènerait tout droit à un comportement indéfini (autrement dit, à une erreur de segmentation).

Je ne serais franchement pas étonné que ce soit ce genre de raisonnement qui ait poussé les gens responsables de la norme à interdire purement et simplement la création de collections de références ;)

(ps: je m'étais trompé de discussion pour cette réponse, la voilà "à la bonne place" :D )

16/05/2013, 16h59
Nicogo

D'accord, je penserai à ça quand je coderai ;p désolé du temps de réponse, mais je n'avais pas le temps ...