isset() en PHP / equivalent en C++ ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/05/2010, 23h15
Doudoupe
Merci Pierre pour ta réponse. ;)
J'ai donc modifier le code en écrivant :
Code:

1 2 3 4 if(joueur1.launchBomb()) { bombQueue.push_back(joueur1.launchBomb()); }
Mais pour le coup ça doit créer 2 bombes (au if et au push_back).
Alors je met:
Code:

1 2 3 4 if(joueur1.getNbbombe() >0) { bombQueue.push_back(joueur1.launchBomb()); }
Donc ça c'est réglé, et je rencontre donc un nouveau problème:
Un problème de linkage apparemment...

Code:

bombeQueue.obj : error LNK2019: symbole externe non résolu __imp___CrtDbgReportW référencé dans la fonction "public: bool __thiscall std::_List_const_iterator<class std::_List_val<class Bombe *,class std::allocator<class Bombe *> > >::operator==(class std::_List_const_iterator<class std::_List_val<class Bombe *,class std::allocator<class Bombe *> > > const &)const " (??8?$_List_const_iterator@V?$_List_val@PAVBombe@@V?$allocator@PAVBombe@@@std@@@std@@@std@@QBE_NABV01@@Z)

Une idée ? J'ai ajouté un #include <list> pour pouvoir utiliser la liste.
Dois-je rajouter quelque chose dans les "librairies supplémentaires" ?

Autre chose, une fois cette liste remplie. Qu'est-ce que j'en fait?
Je pense qu'on doit appeler BombQueue.tick() à chaque tour de boucle de jeu... Mais comment gérer l'affichage de mes bombes présentes dans la liste et l'affichage des explosions lorsque le délai est écoulé ?

(Je dois avouer que je galère pas mal, il me manque quelques connaissances pratiques...)
31/05/2010, 10h58
Invité

Bonjour,
Bon, je me lance.
Je suis ce sujet depuis le début. Manifestement vous débutez, alors autant bien débuter.
Donc, je vais vous donner un conseil.
Fermez votre éditeur de code et ouvrez un éditeur de texte.
Sur cet éditeur, écrivez (forcément en français ou plutôt, pas en langage inlformatique) ce que fait le programme, c'est à dire ce qu'il doit faire et non pas ce que vous avez envie qu'il fasse.
Exemple au hasard:
Le jeu se joue à 2 joueurs.
L'un dispose du clavier, c'est le défenseur, l'autre de la souris.
Chaque joueur dispose d'une certaine quantité de munition etc..

Quand tout cela sera écrit (le développement) il ne restera plus qu'à l'imprimer, fermer l'éditeur de texte, ouvrir l'éditeur de code de programmation, et faire la traduction texte -> code (la programmation).
Je vous assure que ça ira, peut-être pas tout seul du premier coup, mais en tout cas beaucoup plus facilement.
Si vous avez dans votre entourage quelqu'un à peu près au même niveau que vous, passez lui votre texte (le développement vous appartient), il devrait pouvoir faire la traduction en code sans souci, avec son langage préféré, son environnement préféré etc..
En tout cas, il ne faut jamais écrire une ligne de code si on ne sait pas exactement ce qui se passe.

Cordialement.

PS. Si votre langage préféré est le C++, bien sûr vous ferez la traduction en C++
31/05/2010, 13h32
Djakisback

@koala
Je sais que ce n'est pas tout à fait le sujet et que cela ne changera pas les perfs :P
Mais après re-réflexion, je crois que finalement une queue (basée sur une list) n'est pas forcément plus adaptée qu'un vector. En définissant un vector avec une capacité suffisante je pense qu'il n'y aura pas de réallocation à l'insertion d'un nouvel objet (mise a part celle de l'objet lui-même si on alloue sur le tas et aucune si on alloue sur la pile). Etant donné qu'on connaît le nombre de bombes maximum, il me semble qu'une liste chaînée n'a pas vraiment d'intérêt finalement, est-ce que je me trompe ?
Merci d'avance ^^

Le fait est que, si tu dois commencer avec un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 if(boms[0]!=NULL) bombs[0]=b; else bombs[1]=b; /*tester l'explosion... il faut tester TOUTES les bombes :P*/ for( i=0;i<bombs.size();++) { if(bombs[]!=NULL) { if(bombs[i]->elapsed()<=0) { delete bombs [i]; bombs[i]=NULL; } } }
tu te fais du mal pour rien, car tu ajoute des tests inutiles (qui, étant donné qu'il seront effectués de manière très régulière, finiront malgré tout par plomber les perfs, et ce, d'autant plus que tu permettra un nombre important de bombes en même temps :P)

31/05/2010, 15h19
Invité

Bonjour DjakisbacK,
A mon avis, sauf des cas rares comme par exemple le nombre d'élèves dans une classe qui ne devrait pas dépasser 50, il faut éviter à tout prix de fixer a priori le nombre d'éléments d'une liste. Qui vous dit que l'on n'aura pas envie de remplacer les bombes pas des balles de mitrailleuses?
Donc, pour moi, presque dans tous les cas, il faut faire une liste chainée, le détail dépend du cas à traiter (LIFO ou FIFO).
Enfin, là où la performance est importante, une structure spécialisée me parait préférable.
31/05/2010, 17h39
Doudoupe

Citation:

Envoyé par Pierre Dolez

Bonjour,
Bon, je me lance. [...]vous ferez la traduction en C++

Effectivement cela a été fait, au milieu de cette discussion (lorsque je parle d'avoir réorganisé mon code). A partir de cette représentation bas niveau du programme, j'ai définit un diagramme de classe montrant les interactions entre les classes.
De là j'ai complètement ré-écrit mon code en suivant cette représentation.
Seulement je me heurte à des complexités du langage (C ou C++), car effectivement je ne connais pas certaines notions. Par exemple, quand je vois : std::list<Bomb*>::iterator it=bombs_.begin() , j'ai du mal à comprendre comment ça fonctionne... Et c'est pas vraiment sur la version papier de mon prog.

Bref, je n'ai pas vraiment le temps de me justifier là-dessus; personne ne sait d'où vient cette erreur de linkage ? ça vient surement de l'import de <list>...
31/05/2010, 18h08
Invité

Citation:

std::list<Bomb*>::iterator it=bombs_.begin() , j'ai du mal à comprendre comment ça fonctionne...

Rassurez-vous, moi aussi.
En gros, ca veut dire que on déclare un objet nommé bombs
dont le type est "une liste d'objets de type pointeur sur Bomb
puis on parcourt cette, t étant le premier élément.
Personnellement, je n'ai jamais écrit de telles choses :zoubi:

Je vais vous l'écrire de façon un peu plus classique.

Voila un petit exemple basique de liste chainée.

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
33
34
35
36
37
 
struct SListe   // liste des bombes
{               // (dans l'ordre chronologique)
  SListe *suiv;
  Bomb *ptr;       
};
class TListe
{
  SListe *prem;  // le premier de la liste
  SListe *LprDer;  // le dernier de la liste pour un rajour au bout
  public:
    AddBomb(Bomb *bombe);
};
void TListe::AddBomb(Bomb *bombe) 
{
   SListe *L = new SListe;
   if (prem == NULL)
   {
     prem=L;
     prem->suiv=NULL;
     prem->ptr=bombe;
     L->suiv=NULL;  
   }
   else
   {
     L->suiv = NULL;
     L->ptr = bombe;
     LptDer->suiv=L;
   }
   LptDer=L;
}
//Pour parcourir la liste
  for(SListe *lpt=LaListe->prem; lpt; lpt=lpt->suiv)
  {
    Bomb *b=lpt->ptr;
    ...
  }

Je pense que c'est plus facile à comprendre.
Au point de vue performance je crois que c'est imbattable.
Mais, là c'est plus du C que du C++ :cry:

31/05/2010, 19h00
Doudoupe

Ah bah oui pour le coup c'est bien plus clair.
Et il ne devrait pas être difficile d'accéder aux bombes de la liste pour les afficher. Je pense que ça peut le faire! :)

Ok, ce n'est peut être plus du C++, mais ça a le mérite d'être clair pour moi, et ça fonctionnera surement. ^^
Merci pour l'aide Pierre.
31/05/2010, 19h17
koala01
Citation:

Envoyé par Doudoupe

De là j'ai complètement ré-écrit mon code en suivant cette représentation.
Seulement je me heurte à des complexités du langage (C ou C++), car effectivement je ne connais pas certaines notions. Par exemple, quand je vois : std::list<Bomb*>::iterator it=bombs_.begin() , j'ai du mal à comprendre comment ça fonctionne... Et c'est pas vraiment sur la version papier de mon prog.

Bon, on va commencer par le commencement:

C++ autorise un paradigme nommé "programmation générique", et toutes les collections fournies par le standard (vector, stack, queue, list, set, map, ...) utilisent ce paradigme.

L'idée de ce paradigme est simple: si on ne sait pas encore (au moment de créer ces collections) quel type de données nous mettrons dedans, nous savons, par contre, comment les différentes collections vont les manipuler:
Qu'il s'agisse d'une file de voitures, d'une file d'attente aux caisses d'un magasin ou d'une file d'attente pour passer chez le médecin, la manière dont nous en manipulerons les éléments sera, quoi qu'il arrive, toujours la même: les nouveaux arrivants se placeront "en fin de file", et le premier élément "servi" sera celui qui se trouve... "en début de file" et, une fois celui-ci servi, il quittera la file parce qu'il n'a plus rien à y faire ;)

C'est pour cela que nous obtenons l'écriture assez bizare de std::list<Bomb*> (std::list représente le type de collection, et donc la manière dont on manipule les éléments, <Bomb*> indique que nous nous apprêtons à... manipuler des pointeurs sur Bomb ;))

Lorsque l'on manipule des collections d'objets, on se rend compte qu'il faut pouvoir... parcourir l'ensemble de la collection, en respectant certaines règles propre au type de la collection envisagée.

Pour ce faire, chaque type de collection défini ce que l'on appelle un "itérateur", qui n'est, pour faire simple, qu'un "enrobage" de l'objet manipulé de manière à pouvoir passer à l'élément suivant et / ou précédent de la collection.

Seulement, les règles permettant de passer d'un élément à l'élément suivant et / ou à l'élément précédent d'une collection dépendent... du type de la collection utilisée.

Les tableaux associatifs (set et map, par exemple), qui présentent les différents éléments triés de manière automatique, vont utiliser un système "dichotomique", c'est à dire que chaque élément est relié à un élément "plus petit" et à un élément "plus grand" (enfin, s'il y en a un).

Ce principe permet, quand les éléments sont correctement triés, de retrouver une valeur donnée parmis 255 valeurs différentes en maximum... 8 tests successifs :P

Le système FIFO (la std::queue) quant à lui, gère le premier élément ajouté, et le retire de la file, quand le système LIFO gère le dernier élément ajouté avant de le retirer et quand une liste permet de gérer les éléments de manière séquentielle (le premier avant le deuxième qui est lui-même géré avant le quatrième, etc) et qui permet, pourquoi pas, de parcourir les éléments "dans les deux sens" (du premier ajouté au dernier, ou vice versa), voire, d'insérer un élément entre deux éléments déjà présents.

C'est pourquoi, la classe qui sert d'itérateur est... imbriquée dans la collection.

Une classe imbriquée ressemble à quelque chose comme
Code:

1 2 3 4 5 6 7 8 class MaClass { public: class Imbriquee { /*...*/ }; };
Cela implique que, pour arriver à la classe imbriquée, il faut passer par... la classe dans laquelle elle est imbriquée, en utilisant l'indicateur de portée ::.

Je ne peux donc déclarer un instance de Imbriquee que sous une forme de

Code:

MaClass::imbriquee obj;

Lorsque l'on écrit un code proche de

Code:

std::list<Bomb*>::iterator it;

on déclare donc une variable "it" qui est du type de la classe "iterator" que l'on trouve imbriquée dans la classe std::list. Et on prévient que l'on utilise la classe list pour gérer... des pointeurs sur Bomb.

Enfin, il y a au moins deux fonctions intéressantes dans chaque collection: begin(), qui renvoie un... itérateur sur le premier élément de la collection et end(), qui renvoie un... itérateur sur "ce qui suit le dernier élément" de celle-ci.

Comme les itérateurs de toutes les collections présentent une surcharge de l'opérateur d'incrémentation (++) qui fournit... un itérateur sur "l'élément suivant à gérer" (quel que soit le sens que l'on donne à suivant :D), on peut donc écrire une boucle sous la forme de

Code:

for(std::list<Bomb*>::iterator it=laliste.begin(); it!=laliste.end(); ++it)

qui permet de commencer à parcourir la collection au "premier" élément à gérer de continuer tant que l'on a pas atteint "ce qui suit" le "dernier" élément à gérer ;)

Citation:

Envoyé par Pierre Dolez

Personnellement, je n'ai jamais écrit de telles choses :zoubi:

Et pourtant, si tu décide de ne pas te casser la tête à "réinventer" sans cesse la roue pour implémenter les différents type de collections, il y en a certaines (list, set et map en priorité) pour lesquelles tu n'a pas vraiment le choix ;)

Citation:
Envoyé par Pierre Dolez
Voila un petit exemple basique de liste chainée.
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 33 34 35 36 37 struct SListe // liste des bombes { // (dans l'ordre chronologique) SListe *suiv; Bomb *ptr; }; class TListe { SListe *prem; // le premier de la liste SListe *LprDer; // le dernier de la liste pour un rajour au bout public: AddBomb(Bomb *bombe); }; void TListe::AddBomb(Bomb *bombe) { SListe *L = new SListe; if (prem == NULL) { prem=L; prem->suiv=NULL; prem->ptr=bombe; L->suiv=NULL; } else { L->suiv = NULL; L->ptr = bombe; LptDer->suiv=L; } LptDer=L; } //Pour parcourir la liste for(SListe *lpt=LaListe->prem; lpt; lpt=lpt->suiv) { Bomb *b=lpt->ptr; ... }
Je pense que c'est plus facile à comprendre.
Au point de vue performance je crois que c'est imbattable.
Cela pourrait pourtant encore être améliorer, au moins en terme d'écriture, sous la forme de
Code:

1 2 3 4 5 6 7 8 9 10 void TListe::AddBomb(Bomb *bombe) { SListe *L = new SListe; if (prem == NULL) prem=L; if(LprDer->suiv!=NULL) LprDer->suiv=L; lprDer = L; L->ptr = bombe; }
(et tu as, surtout, oublié de montrer le destructeur de TListe, qui se doit quand même de gérer la libération correcte de l'ensemble :aie:)

Mais, ceci dit, c'est à peu de choses près exactement ce que fait la liste pour ajouter un objet, avec, en plus, la possibilité (parce que certains peuvent en avoir besoin) d'ajouter un élément... en début de liste, voir, d'en insérer un entre deux éléments (sans oublier les possibilités équivalentes d'insertions multiples :D)

31/05/2010, 19h50
Invité

Naturellement, tout cela est vrai aussi.
1- j'ai écrit ces fonctions il y a près de 10 ans, et je n'ai jamais éprouvé le besoin d'y remettre le nez.
2- pour la simplification de l'explication, j'ai supprimé quelques lignes utiles mais hors-sujet.
3- naturellement la destruction de ces listes est prévue et fonctionne très bien (mon compilateur dispose d'une option qui me permet de vérifier que je n'ai pas de fuite de mémoire)
4- naturellement j'ai des fonctions qui permettent d'insérer un élément (début, fin ou n'importe où).
5- naturellement j'ai des fonctions qui permettent de supprimer un élément de couper une liste, de rabouter 2 listes, d'inverser etc.

D'autres questions?
Je suis à ta disposition.

PS im manque un chose fondamentale dans ta nouvelle mouture, c'est de mettre le suivant à NULL, si c'est le dernier :P
Tu remarqueras que c'est le test dans la boucle de parcours.
31/05/2010, 20h02
koala01

Citation:

Envoyé par Pierre Dolez

Naturellement, tout cela est vrai aussi.
1- j'ai écrit ces fonctions il y a près de 10 ans, et je n'ai jamais éprouvé le besoin d'y remettre le nez.
2- pour la simplification de l'explication, j'ai supprimé quelques lignes utiles mais hors-sujet.
3- naturellement la destruction de ces listes est prévue et fonctionne très bien (mon compilateur dispose d'une option qui me permet de vérifier que je n'ai pas de fuite de mémoire)
4- naturellement j'ai des fonctions qui permettent d'insérer un élément (début, fin ou n'importe où).
5- naturellement j'ai des fonctions qui permettent de supprimer un élément de couper une liste, de rabouter 2 listes, d'inverser etc.

Mon intervention était surtout faite pour attirer l'attention de Doudoupe sur le fait qu'il manquait "quelque chose" :D

J'espérais quelque part en effet que tu pensais aussi aux parties manquantes :D

Citation:

D'autres questions?
Je suis à ta disposition.

Pas vraiment une question, mais plutôt une remarque:

A chaque fois que tu va devoir gérer une liste, tu va te retrouver à... recopier quasiment la même chose que la liste (qui manipule un autre type d'objet) que tu viens de terminer (ou que tu as écrit la veille)...

Ca fait quelques heures à prester, mais ca augmente le risque d'erreur de copie, et c'est, quelque part, dommage :aie:

Surtout quand on sait que le langage fournit une classe qui fait exactement la même chose, pour laquelle tu as la certitude (du fait du nombre de paires d'yeux qui y jettent régulièrement un oeil) qu'elle aura été optimisée et entièrement débuggée.

Comme je l'ai dit, tu t'astreint à... réinventer la roue à chaque fois ;)
01/06/2010, 11h02
Invité

Bonjour,
Ce principe de répétition lorsqu'on a une autre liste à écrire n'est pas tout à fait exact pour plusieurs raisons.
En réalité ma structure SListe peut contenir d'autres membres, ce qui est effictevement le cas, mais je les supprimés pour la clarté de l'explication.
L'écriture d'une telle liste n'est pas une simple recopie. Etant donné qu'elle sera très utilisée, elle est écrite avec soin.
Enfin, si j'ai besoin d'une liste pour laquelle je n'ai pas besoin de performances particulières, j'utilise TList de Borland. Je ne sais pas comment elle est faite, mais ce n'est pas ma préoccupation.

Enfin, pour rester (ou revenir) dans le sujet, je préfère employer des mots et un langage que mon interlocuteur comprendra, sinon ça ne sert à rien de parler.

Citation:

Envoyé par Pierre Dolez

Enfin, si j'ai besoin d'une liste pour laquelle je n'ai pas besoin de performances particulières, j'utilise TList de Borland. Je ne sais pas comment elle est faite, mais ce n'est pas ma préoccupation.

Sauf erreur, elle est faite à peu près comme la liste de la STL, car, toujours sauf erreur, il s'agit, là aussi, d'une implémentation générique.

A ma connaissance, en ce qui la concerne, il y a peut être deux différences (qu'il faudrait vérifier):
1- il s'agit *peut-être* d'un portage de l'implémentation qui est faite en pascal

2- Comme pour beaucoup de framework, l'implémentation des conteneurs a été fournie par une implémentation personnelle car elle date d'une époque où ceux-ci n'étaient pas forcément bien standardisés.

Citation:

Enfin, pour rester (ou revenir) dans le sujet, je préfère employer des mots et un langage que mon interlocuteur comprendra, sinon ça ne sert à rien de parler.

Ca, ca me fait me poser la question de savoir si tu as déjà regardé correctement les différents conteneurs de la stl, et surtout, leur interface.

Les termes utilisés ont beau être en anglais, ils sont parfaitement compréhensibles ("push" et "back" sont, malgré tout simple à comprendre, même si on ne parle pas anglais :D) et, cela représente malgré tout un avantage certain, ils sont "uniformisés" dans le sens où, si deux conteneurs doivent présenter un comportement identique ("push back" peut aussi bien s'appliquer au tableaux qu'aux listes :D), la fonction présentant ce comportement portera le même nom et les mêmes possibilités d'arguments.

Au final, une fois que tu auras déterminer la manière dont les différents éléments doivent être géré dans ton conteneur, tu peux parfaitement ne plus tenir compte du type de conteneur, simplement en définissant les alias de type ad-hoc:
Code:

1 2 3 4 5 6 typedef std::list<int> collection; // la collection prend la // forme d'une liste typedef collection::iterator iterator; // m'iterateur avec acces en // écriture possible typedef collection::const_iterator const_iterator;// l'itérateur avec acces en // lecture seule
On peut de la même manière décider de gérer les éléments plutôt sous la forme d'un tableau:
Code:

1 2 3 4 5 6 typedef std::vector<int> collection; // la collection prend la // forme d'un tableau typedef collection::iterator iterator; // m'iterateur avec acces en // écriture possible typedef collection::const_iterator const_iterator;// l'itérateur avec acces en // lecture seule
et cela permet une utilisation tout à fait transparente pour l'utilisateur:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 int main() { // l'utilisateur n'a qu'à savoir que collection permet de gérer // une collection de int, et que ce n'est pas un tableau associatif collection col; col.push_back(1); col.push_back(5); col.push_back(10); for(const_iterator it=col.begin();it!=col.end();++it) std::cout<<(*it)<<std::endl; std::sort(col.begin(),col.end()); for(const_iterator it=col.begin();it!=col.end();++it) std::cout<<(*it)<<std::endl; // col.push_fron(152); /* ne fonctionnera qu'avec une liste d'entiers */ // col[0]=153; /* ne fonctionnera qu'avec un vector d'entiers */ return 1; }

Voir 40 message(s) de cette discussion en une page