Création d'objets dans une boucle

Bonjour !

Je suis en train de suivre un tutoriel (SdZ) pour apprendre à programmer en C++. Nous avons créer une classe Personnage et une autre Arme (sans importance ici).
Je voudrais qu'au début du programme, le nombre de personnages/de joueurs soit saisi et qu'ensuite ceux-ci soient créés.
Je pensais faire une boucle for mais ne voit pas comment créer les objets dedans (d'autant plus qu'ils seront détruits à la fin de la boucle). J'ai pensé aux vectors mais ne vois pas comment faire. J'ai essayé ceci mais ai 1 erreur et 3 notes :

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 31 32

#include <iostream> #include <string> #include <vector> #include "Personnage.h"   using namespace std;   int main() { int i,nbJoueurs; string nomPersonnage;   cout<<"<--------------------- Jeu de combats magiques --------------------->"<<endl<<endl;   do { cout<<"Nombre de joueurs : "; cin>>nbJoueurs; }while(nbJoueurs<2);   vector<Personnage> tabJoueurs;   for(i=0;i<nbJoueurs;i++) { cout<<"Nom du joueur : "; cin>>nomPersonnage; Personnage* joueur = new Personnage(nomPersonnage); tabJoueurs.push_back(joueur); }   return 0; }

---

avec :Pièce jointe 154575

De plus, j'ai trouvé cela sur internet. Je ne connais pas encore new ni l'astérique après le type Personnage...

Je vous remercie par avance de votre aide !

AdelineJ

Cela désigne les pointeurs.
Un pointeur stocke l'adresse mémoire d'une autre variable, et new alloue une variable dans une partie extérieure de la mémoire (le tas).
Pour l'instant, tu ne sembles pas en avoir besoin, donc je te laisse le temps d'y arriver.
Tu as un peu de temps avant d'en avoir besoin.
Sache que le pointeur à base de new et d'étoile n'est pas la meilleure solution. En général, on préfèrera les "smart pointers" tels que std::unique_ptr.



Par contre, c'est une erreur du tuto, enlève les, simplement.

Code:

---

1 2	Personnage *joueur = new Personnage(nomPersonnage); tabJoueurs.push_back(joueur);

---

devient alors

Code:

---

1 2	Personnage joueur = Personnage(nomPersonnage); tabJoueurs.push_back(joueur);

---

en utilisant le constructeur immédiatement:

Code:

---

1 2	Personnage joueur(nomPersonnage); tabJoueurs.push_back(joueur);

---

et en ne créant pas de variable locale pour rien

Code:

---

tabJoueurs.push_back(Personnage(nomPersonnage));

---

Et en utilisant la fonction membre .emplace_back(...) (disponible dès C++11) qui prend directement les paramètres du constructeur :

Code:

---

tabJoueurs.emplace_back(nomPersonnage);

---

Je l'avais oublié, celui-là

[HS]un peu étrange quand même de faire un tuto sur SDZ et poster sur DVP.:ptdr:[/HS]

Salut,

Tu as déclaré un std::vector contenant des Personnages et pas des pointeurs sur des personnages. Or tu push_back un pointeur sur un personnage.
Donc soit tu fais:

Code:

---

1 2 3

std::vector<Personnage> tabJoueurs; tabJoueurs.push_back(Personnage(nomPersonnage));

---

Soit tu fais (note le std::vector de pointeur de personnage):

Code:

---

1 2 3

std::vector<Personnage*> tabJoueurs; tabJoueurs.push_back(new Personnage(nomPersonnage));

---

Attention pour la deuxième solution, tu ne dois pas oublier de delete avec l'opérateur du même nom chaque instance que tu alloues avec new.

Ok pour la syntaxe (à part que c'est std:: et non sd::).

Il n'y a aucune raison à avoir un tableau de pointeurs nus de personnages. Si on veut du polymorphisme d'inclusion, on peut utiliser std::unique_ptr (ou faire en sorte que ce soit un détail interne de l'implémentation des personnages) :

Code:

---

1 2	// std::vector<Personnage*> tabJoueurs; // À bannir d'un programme C++ moderne std::vector<std::unique_ptr<Personnage>> tabJoueurs;

---

PS : pour créer un std::unique_ptr, utiliser directement new en C++11 :( ou un équivalent de std::make_unique de C++14 :)

cela dit, tu peux pomper make_unique dans un header à toi.

Citation:

---

Il n'y a aucune raison à avoir un tableau de pointeurs nus de personnages.

---

Tu en as des raisons mais tout le monde ne travaille pas avec un compilo compatible C++11 et c'est bien de savoir comment travailler avec des pointeurs nus et std::unique_ptr.
Il ne faut pas oublier les racines ;) et si AdelineJ ne comprends pas ça, l'envoyé sur un std::unique_ptr sans combler sa lacune sur la compréhension des pointeurs est une erreur d'apprentissage selon moi

Citation:

---

Envoyé par Astraya

Tu en as des raisons

---

Lesquelles ?

Citation:

---

Envoyé par Astraya

tout le monde ne travaille pas avec un compilo compatible C++11

---

Je parle de std::unique_ptr pour donner une référence. Ceux qui n'ont pas de compilateur C++11 (sic) peuvent trouver un équivalent (boost::unique_ptr par exemple) voire l'implémenter (là ils comprendront bien comment ça marche ;)).

Citation:

---

Envoyé par Astraya

c'est bien de savoir comment travailler avec des pointeurs nus

---

Admettons, j'ai pas vraiment d'avis là dessus.
C'est important de savoir comment fonctionne la mémoire (pour comprendre et débugger plus facilement), les pointeurs permettent d'avoir un vocabulaire commun mais c'est plus un moyen qu'une finalité.

Citation:

---

Envoyé par Astraya

AdelineJ ne comprends pas ça, l'envoyé sur un std::unique_ptr sans combler sa lacune sur la compréhension des pointeurs est une erreur d'apprentissage selon moi

---

Oui je suis d'accord avec ça ;) personne le prend le temps de bien expliquer, car expliquer les pointeurs est long.
En tout cas, ici, ce n'est clairement pas le bon exemple, comme l'a dit leternel « les pointeurs [...] tu ne sembles pas en avoir besoin ».
Pour moi les pointeurs (intelligents) doivent être vus lorsque on a besoin d'une collection d'objets polymorphes.
Et les pointeurs nus doivent être expliqués à la toute fin, dans des annexes (mais on peut y faire en faire référence avant).

Le but de mon message était de donner une référence à std::unique_ptr et dire quand utiliser ça (polymorphisme d'inclusion par exemple).
Je ne cherche pas à l'expliquer, ni dire pourquoi mais au moins les personnes qui lisent ça, on une chance de se renseigner dessus (et éviter de partir sur des "mauvaises solutions").

--- --- ---

@AdelineJ
new, new [], delete et delete [] permettent de gérer l'allocation mémoire dynamique "à la main". Cela est "dangereux" car il est "facile" de faire des oublis et des erreurs ; c'est pour cela que l'on évitera d'utiliser n'utilisera pas les pointeurs nus en C++. De plus les pointeurs nus ont aucune sémantique (qui est responsable de l'objet ? est-ce un pointeur ou un tableau à la C ?).
C++ évolue et offre maintenant des solutions "propres" :
- std::unique_ptr qui a la responsabilité de l'objet
- std::shared_ptr et std::weak_ptr pour partager la responsabilité de l'objet
- std::reference_wrapper pour "référencer" un objet
- pour d'autres usages, on peut imaginer clone_ptr, copy_ptr et view_ptr (mais j'ai pas encore assez de recul pour ceux là)
- et std::vector pour les tableaux

Citation:

---

Lesquelles ?

---

Ce n'est pas vraiment lié son cas de figure ici mais bon... J'ai travaillé dans deux grosses entreprises connues (Jeu vidéo). Un moteur maison dans chacune, et bien je t'assure que std::unique_ptr n'est pas utilisé pour des raisons que ton code doit être un minimum dépendant d'une librairie (std compris) et encore plus de boost qui est bien mais gros et complexe à tweaker ou dans le meilleur des cas c'est une std::unique_ptr maison.

Ce sont de bonnes librairies adaptées dans la plupart des cas je ne dit certainement pas le contraire. Elles répondent efficacement à beaucoup de problèmes. Mais si tu veux faire un code fonctionnant sur diverse architecture/compilateur/librairie correspondant à tes exacts besoins sans plus ni moins tu dois utiliser les pointeurs et savoir les utiliser... Rien que compiler ton C++ sur Android...maintenant l'intégration C++ est correct mais avant....
Si tu veux que ton code soit réactif au nouvelle technologie utilise le moins possible les librairies c'est tout ce que je veux dire :) et Android NDK en est un bon exemple.
Mais la je m’égare ^^

Alors oui dans son cas elle peut utiliser std::unique_ptr mais il est archi faux de dire qu'il ne doit pas y avoir de pointeur.
Je lui conseille fortement de faire avec des pointeurs de comprendre ces erreurs, ces fuites mémoires et la logique de libération de la mémoire et ensuite elle peut jouer avec les std::unqiue_ptr.

Donc quand je vois ça:

Code:

---

Personnage* joueur = new Personnage(nomPersonnage);

---

Bas je me dit qu'elle apprend l'allocation mémoire :) donc... on la fait apprendre à utiliser ceci. Ça fait partie des contraintes de programmeur, avoir accès/droit à certaines fonction ou non :)
De plus, appeler delete puis vider le std::vecteur peut avoir un aspect pédagogiquement intéressant :)

Citation:

---

Cela est "dangereux"

---

C'est dangereux si tu travaille avec quelqu'un qui ne sait pas utiliser l'allocation mémoire correctement. Sinon le programmeur est le seul responsable de son incompétence en la matière.

Citation:

---

De plus les pointeurs nus ont aucune sémantique (qui est responsable de l'objet ? est-ce un pointeur ou un tableau à la C ?)

---

Faux. Ils en ont juste plusieurs :)

(Troll on) Sinon autant apprendre Java directement et oublions le reste :zoubi:(Troll off)

Ensuite tout dépends du développeur, personnellement je déteste les pointeur intelligent. Je préfère nettement passer par des pointeurs nus, ça évite bon nombre de soucis de compilation et de prise de tête.
Je suis bien conscient que l'évolution tend vers les pointeur intelligent, mais du coup on finit par se restreindre énormément.
Pour moi l’intérêt du langage tel que le C++ ou le C est de pouvoir géré ces pointeur à la volé comme on veut, donc j'évite d'utiliser ces pointeurs.

Et je rejoins l'avis d'astraya concernant l'apprentissage des pointeurs nu puis des pointeur intelligent, de la même manière qu'on apprends le write avant le printf ou le std::cout :).

Concernant tout cela, et bien d'autres choses, je pense que notre amie a un peu de temps avant de s'y intéresser.
AdelineJ , je t'invite à visiter notre FAQ C++, très riche en explications.

Citation:

---

Envoyé par leternel

Concernant tout cela, et bien d'autres choses, je pense que notre amie a un peu de temps avant de s'y intéresser.
AdelineJ , je t'invite à visiter notre FAQ C++, très riche en explications.

---

J'ai aussi écrit un tutoriel sur le sujet : http://loic-joly.developpez.com/tuto...mart-pointers/

Citation:

---

Envoyé par Astraya

C'est dangereux si tu travaille avec quelqu'un qui ne sait pas utiliser l'allocation mémoire correctement. Sinon le programmeur est le seul responsable de son incompétence en la matière.

---

A moins de vivre dans un territoire sans exception, la seule façon d'utiliser la mémoire correctement consiste à la confier à des capsules RAII-like.
Certains ont des illusions de maitriser le code quand il n'y a que des pointeurs bruts, mais ce n'est que ça : une illusion. Il suffit d'une exception, pffiout, il y a une fuite (ou pire, un dangling pointer). Pour la démo, cf. l'article (usuel) d'Aaron Lahman -> http://alexandre-laurent.developpez....ou-exceptions/

Quant à unique_ptr, il ne coute rien. S'en passer n'a aucun sens -- quand on a accès à un compilo C++11. NB: l'unique_ptr de boost souffre des limitations du C++03. Il est à peine mieux que std::auto_ptr. Quitte à sortir boost, c'est boost::ptr_vector<> qu'il faut regarder en C++03 pour des vecteurs de pointeurs.

Citation:

---

A moins de vivre dans un territoire sans exception, la seule façon d'utiliser la mémoire correctement consiste à la confier à des capsules RAII-like.

---

Je suis d'accord. Pour se protéger de l’exception au new il existe tout de même nothrow, sachant que l'utilisation des exceptions peut être couteuses et difficile à gérer dans des cas complexes de "Poupée russes".

Citation:

---

Quant à unique_ptr, il ne coute rien.

---

Il coute un déréférencement de plus, alors ce n'est rien dans 99% des cas, mais cela peut couter cher sur un tableau de unique_ptr. C'est toujours bon de savoir que il y a tout de même un déréférencement en plus avec std::unique_ptr.
Un mec a fait un article sur ce cout ici
Mais je ne dit pas que les std::unique_ptr c'est mal, j'aime bien l'utiliser aussi :)

Les exceptions coutent chers quand on sort via un chemin non nominal. C'est vrai. Sur un chemin nominal, elles vont plutôt tendance à réduire les coûts -- à condition de comparer avec un code correct (i.e. un code où les perfs sont pourries avec un if toutes les deux lignes pour gérer les remontées d'erreurs, et pas un code du pays magique où les erreurs n'existent pas).

Côté difficultés, tout faire à la main est bien plus complexe que de mélanger RAII et exception. Il faut juste arrêter de supposer qu'une ressource se nettoie avec un catch. Après, il reste les cas tordus (tout langage confondu) où le nettoyage de ressource peut échouer.

Un déréférencement de plus qu'avec l'objet brut, mais à ma connaissance pas un déréférencement de plus que le pointeur nu.

bah, normalement, on a quelque part au fond de unique_ptr quelque chose comme T& operator*() {return *data;}.
Ce qui signifie appeler unique_ptr<T>::* puis T::* à chaque accès

C'est forcément plus qu'un pointeur nu.
Sauf si c'est effectivement inliné par le compilateur.

PS: J'en conviens, ce n'est pas un déréférencement, mais un appel de méthode.

Ce n'est rien ça. Une classe template a son code inliné. Et vu la taille plus que réduite du code, il y a de très fortes chances que cela soit effectivement inliné dans le binaire final.