Version imprimable
Bonjour.
J'aimerais savoir s'il existe une fonction en C++ qui permet de vérifier si une variable est initialisé ou non.
En PHP, cette fonction existe, il s'agit de isset() qui renvoie un bolléen. Qu'en est-il du C++ ?
Si une telle fonction n'existe pas, comment l'implémenter ?
Merci.
Salut,
Non. C'est pour ça que tu dois les initialiser à leur définition. Que veux-tu faire exactement ?
En fait, je réalise un jeu en 2D style Bomberman, avec la SDL.
Lorsqu'une bombe est posé (collage d'une surface bombe avec SDL_BlitSurface), il faut un délai d'environ 3 secondes avant qu'elle n'explose (collage d'une surface explosion avec SDL_BlitSurface par dessus la surface bombe).
Voici ce qu'on m'a conseillé :
Je trouve la formulation pas très compréhenssible mais ça m'a donné l'idée de stocker le timestamp de la création de l'objet bombe dans un de ses attributs (startTime par exemple).Citation:
La bombe est un ojbet qui a un membre "startTime" qui est le timestamp du moment ou tu a laché la bombe.
A chaque itération (ou N itérations) de ta boucle de jeu, tu vérifie si ce startTime + 3000 est supérieur au timestamp actuel, si c'est le cas, tu explose la bombe.
Ensuite et à chaque autre ittération de la boucle de jeu, on vérifie que le timestamp actuel est supérieur ou égal à startTime + 3000 (en ms). Si VRAI alors on fait explosé la bombe.
Le problème c'est qu'à chaque boucle de jeu, j'initialise startTime à time(0) donc le timestamp actuel, du coup ma vérification me renvoie toujours FAUX puisque c'est comme si je faisait if(time(0) >= time(0)+3000) ; et ma bombe n'explose jamais.
De ce fait, il me faut une fonction (celle de isset en php) qui de permette de faire ceci :
J'espère que je suis assez clair.Code:
2
3
C'est plutôt un problème de conception. Il faut que tu initialises ta variable au moment où tu 'poses' la bombe. Pas en permanence. Je pense qu'il faut plus travailler sur ton design plutôt que de chercher une astuce du langage.
Oui effectivement c'est ce que je cherche à faire.Citation:
Envoyé par 3DArchi
Mais qu'entends tu par travailler sur mon deisgn ? Je ne vois pas de quelle manière ça pourrait régler mon problème.
Au niveau de la conception, lorsqu'on presse la touche espace, ça appelle la fonction constructrice Bombe de la classe Bombe. Il y a une méthode explose que doit etre appellé automatiquement 3 secondes plus tard.
Que revoir de ma conception.
Désolé, je dois avouer que je me suis un peu perdu avec ce détail.
startTime devrait être initialisé dans le constructeur de Bombe si cela correspond à fonction constructrice.
Bref, peux-tu poster une version simplifier de ton code pour avoir plus d'éléments (pas 42 fichiers car je n'aurais pas le courage de les lire ;) )
Voilà ma classe bombe (appelée avec un évènement clavier).
Ensuite je réalise que je ne comprend pas vraiment le terme (que j'utilisais en plus), de "ma boucle de jeu". Il s'agit de cette boucle ?Code:
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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
---->
Je n'ai pas encore codé les évènements claviers. Je me pose d'ailleurs la question, devrai-je les coder dans cette boucle ( haut,bas,gauche,droite pour déplacer un joueur par ex) ou recréer une boucle "quelques part" avec un SDL_WaitEvent dedant?Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Merci 3DArchi de prendre un peu de tps pour m'aider. :)
Si tu as besoin de plus d'info...
Je ne sais pas si les jeux se font encore sur ce schéma là, mais effectivement, c'est à ce genre de boucle que je pensais. Boucle qui ressemble grosso modo à ce que tu présentes :Citation:
Envoyé par Doudoupe
while(1) :
-> lire entrees
-> traiter entrees
-> construire affichage
-> afficher
Ce qui est sur c'est que tu devrais au - avoir un objet dédié pour ne pas avoir des choux et des carottes dans ta 'boucle de jeu'. Ceci dit, le principe de la boucle est de faire plutôt du polling que de l'évènementiel. C'est à dire qu'au lieu d'attendre la réception d'un message, à chaque déroulement de ta boucle du lis l'état des touches et tu réagis en fonction de cet état. Mais je ne connais pas la SDL et peut être permet-elle plus facilement une approche fonctionnelle. Je t'invite à regarder du côté de la rubrique jeux (qui a un forum SDL) pour avoir plus d'info sur ces aspesCitation:
Envoyé par Doudoupe
Le constructeur d'un objet n'est appelé qu'au moment où l'objet est défini. Il doit retourner un objet valide et prêt à être utilisé. Je pense que ton constructeur en fait trop : il initialise l'objet, il le dessine et il veut gérer le timer. Il devrait s'arrêter à l'initialisation de l'objet. Le rendu et la gestion du timer devrait être orchestrés par le moteur de jeu ci-dessus.Citation:
Envoyé par Doudoupe
Salut!
Bon depuis la dernière fois, j'ai remis à neuf mon code de manière structuré, donc j'ai pu résoudre pas mal de problème, et éclaircir des points que je ne comprenais pas trop.
Bien entendu, j'ai encore quelques soucis. Et ça revient un peu au sujet initial.
Je vous expose donc la structure de ma boucle de jeu:
Le problème est donc dans l'instanciation de bombe1 à l'intérieur d'un case.Code:
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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
N'étant pas déclaré dans les autres cas d'event, le compilo plante.
Il faudrait donc que depuis ma boucle de jeu, je puisse accéder à la fonction update (où qu'il soit).
La fonction update suit ce cheminement:
Où dois-je placer cette méthode?Code:
2
3
4
5
6
7
Help me please!
(si points sombres, hésitez pas ;) )
Salut,
Visiblement, tu te base sur le fait que ton joueur n'a qu'une quantité "limitée" de bombe...
Mais pourquoi vouloir faire en sorte qu'il... dispose réellement d'une collection de bombe "pré créées" :question:, il n'en a absolument pas besoin :P
Au pire, tout ce qu'il doit garder en mémoire, c'est un moyen de "compter" les bombes qu'il a posées ou celle qu'il a encore en stock, et, lorsque tu veux qu'il en lance une, tu vérifie, simplement, s'il a "atteint son cota" ou non ;)
S'il a atteint son cota, il ne te fournit pas de bombe, et, s'il ne l'a pas encore atteint, il la crée et te la donne ;)
Cela donnerait quelque chose comme:
la fonction launchBomb() prendrait alors une forme proche deCode:
2
3
4
5
6
7
8
9
10
11
12
Dans la fonction principale, tu peux donc te contenter d'unCode:
2
3
4
5
6
7
8
9
10
11
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Bah en fait pour ma "collection de bombe", c'est pour accéder à soit la bombe 1 soit la bombe 2, pour appeler notamment la fonction update(). Mais j'ai tout de même un compteur de bombe qui vérifie sur le même schéma que toi (launchBomb) si je peux ou pas poser une bombe. Ce n'est pas une bonne solution?
Le nombre de bombe est de 1 ou 2, lorsqu'une explose, elle est "redonnée" au joueur.
En ce qui concerne le fait de renvoyer un objet Bombe avec launchBomb, ça a l'air pas mal. Je fais quelques tests. ;)
***
EDIT : Mais c'est pareil, je ne peux pas accéder à l'objet Bomb à l'extérieur de mon switch pour appeler ma fonction update...
De plus le prototype Bombe* poserBombe(); a l'air de passer à la compilation, mais Bombe * Joueur::poserBombe() {...} est rejeté par le compilo.
Un problème d'étoile/pointeur ??
***
Et qu'est ce que BombQueue.pushback()?
merci pour tes réponses
Salut,
BombQueue c'est ta file de bombes.
C'est ce qui contient toutes les bombes actives et que tu dois parcourir et mettre à jour à chaque loop.
De mon côté, je passerais l'elapsed time à la méthode update() de Bomb.
Sinon ceci :
explosion = IMG_Load("image/explosion.png");
est mauvais pour les perfs, tu charges un fichier à la volée de manière récurrente. Il faudrait que stockes ça ailleurs et que tu le blittes en tant voulu.
[edit] et après relecture, tu fais la même chose dans ton constructeur :
bombe = IMG_Load("image/bombe.png");
A chaque fois que tu crées une bombe ou qu'elle explose tu charges un fichier.
Le mieux serait de passer les surfaces dans ton constructeurs ou gérer ça à l'extérieur de la classe.
@ Djakisback:
Effectivement c'était le gros problème de mon code. Mais j'ai réorganisé mon code (2-3 posts au dessus). Ma boucle de jeu est dans une classe Affichage qui gère l'affichage. Les IMG_Load sont donc appelés une seule fois avant les boucle de jeu. ;)
Pour BombQueue, je me suis douté que c'était la file des bombes actives (même s'il n'y en a maximum que 2 dedans). Mais d'où vient elle? et comment la coder ?
Voici à peu près ce que je te proposerais:
Un joueur doit (outre le fait de gérer ses points de vies et sa position, ce que je ne présente pas ici) décider s'il peut lancer ou non une bombe.
Tout ce qu'il doit avoir, c'est le nombre de bombe qu'il peut lancer "en même temps" (en fait, le nombre de bombe à lui qui peuvent apparaitre en même temps sur le plateau de jeu).
Je l'ai arbitrairement défini à 40... à toi de lui donner la valeur qui t'intéresse :D
La priorité de la bombe(outre le fait de gérer sa position sur le plateau et de pévenir ce dernier au moment où elle explose, ce que je ne présente pas ici), c'est de gérer le moment de son explosion.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
J'ai arbitrairement défini le délai entre sa création et son explosion à 15... à toi de lui donner la valeur qui t'intéresse :D
Si, chaque fois qu'une bombe explose, elle doit permettre au joueur qui l'a lancée d'en lancer une nouvelle, elle devra également prévenir ce dernier qu'elle explose, au moment où cela se produit.
les fonctions membres qui doivent connaitre une autre classe (quand Joueur doit connaitre Bomb et que Bomb doit connaitre Joueur)Code:
2
3
4
5
6
7
8
9
10
11
12
la file d'attente de gestion des bombes.Code:
2
3
4
5
6
7
8
9
10
11
Elle s'occupe principalement de deux choses:
1 -de garder une trace de toutes les bombes qui sont, à un instant T, présentes sur le plateau de jeu
2 -de donner un "tick" à intervalle régulier à chaque bombe (ce tick permet au bombe de calculer le délais avant l'explosion :D)
Comme toutes les bombes ont un délai avant l'explosion identique, la première bombe lancée sera... la première à exploser, et donc, la première à quitter la file :D
la fonction membre tick a besoin de la définition complète de bombeCode:
2
3
4
5
6
7
8
9
10
11
12
13
Et notre fonction main devient donc quelque chose commeCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
L'idée générale est en effet que, une fois que le joueur a lancé une bombe, il perd totalement le contrôle sur celle-ci, et que c'est à la liste d'attente de prendre le relais pour "la suite des événements" :DCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
En fait, tu peux utiliser un vecteur : http://www.cplusplus.com/reference/stl/vector/ pour stocker tes bombes :
Sur la pile :
std::vector<Bombe> bombes;
Et pour le parcours ça doit donner ça je pense :
A la fin de ton explosion, tu mets un attribut destroyed à true pour indiquer que la bombe doit être supprimée. Pour ce qui est de l'update, une autre méthode (qui est plus simple a priori) et de stocker la durée plutôt que le startTime. T'initialises par exemple la durée à 1000 ms dans le constructeur de Bombe et dans update :Code:
2
3
4
5
6
7
8
9
10
Code:
2
3
4
5
6
7
8
9
10
11
(Si tu fais des allocations dynamiques, il faudra que tu supprimes également les pointeurs de ton vector)
Plus d'infos sur les méthodes des vecteurs :
http://cpp.developpez.com/faq/cpp/?page=STL#STL_vector
(Je ne sais pas si koala01 avait une idée précise en tête en utilisant une file. Effectivement une file pourrait être intéressante mais dans le cas où tu ne veux pas détruire/recréer tes objets mais les réutiliser.)
[edit] Bin comme ça, t'auras 2 versions ;)
Celle de koala01 sera sans aucun doute mieux codée, en revanche je ne comprends pas pourquoi tu veux passer par une Queue personnalisée.
La classe vector ne serait pas intéressante dans le cas présent...Citation:
Envoyé par Djakisback
En effet, il faut savoir que la classe vector est en interne strictement identique à un tableau "C style", avec toutes ses restrictions (entre autres lorsqu'il s'agit de modifier le nombre d'éléments qu'il contient, même si cela se fait de manière amortie).
Comme on sait que l'on peut utiliser un système FIFO (First In First Out: le premier élément entré est le premier élément à sortir) de par le fait que toutes les bombes ont un délais avant explosion identique, il est largement préférable de choisir une collection qui permet l'ajout d'élément après le dernier élément et le retrait du premier élément.
La std::queue fournit ces comportements, mais on ne peut normalement pas parcourir les éléments de cette collection sans... retirer à chaque fois le premier.
C'est la raison pour laquelle je propose d'utiliser la std::list, même si on n'en utilise pas forcément toutes les capacités (entre autres, celles d'insérer un élément "n'importe où" ou celle de parcourir la liste "à reculons")
Le fait est qu'il me semble plus facile de créer une bombe "à la demande" qui sera d'office correctement initialisée et de la détruire quand on en n'a plus besoin que de commencer par... vérifier si on peut réutiliser une bombe pour décider de la remettre dans un état "cohérent" avec son utilisation, tout simplement ;)Citation:
(Je ne sais pas si koala01 avait une idée précise en tête en utilisant une file. Effectivement une file pourrait être intéressante mais dans le cas où tu ne veux pas détruire/recréer tes objets mais les réutiliser.)
D'autant plus que, à bien y réfléchir, ce n'est jamais la même bombe que l'on utilise, vu qu'elle a été "physiquement" détruite... on ne va pas commencer à chercher ses morceaux hein :question:
Merci pour ces informations précieuses :P
Effectivement c'est plus optimisé.
@koala
Merci beaucoup pour les précisions. ;)
Je n'ai jamais pensé à faire une classe BombQueue qui gerera toutes mes bombes.
Je vais donc suivre cette piste. Et voir ça plus en détail ce soir. :)
Bon ça l'air de concorder mais j'ai des erreurs à la compilation :
error C2360: l'initialisation de 'b' est ignorée par l'étiquette 'case'
(et cette erreur à chaque "case" qui suit notre case SPACE.)
Tu as quelques infos koala ?
Bonjour,
Juste une réponse à la question sur l'erreur de compile
Une case est une adresse de branchement, et non un bloc d'instructions. C'est pourquoi il est interdit de déclarer une variable dans une case.
VoilaCode:
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
Merci Pierre pour ta réponse. ;)
J'ai donc modifier le code en écrivant :
Mais pour le coup ça doit créer 2 bombes (au if et au push_back).Code:
2
3
4
Alors je met:
Donc ça c'est réglé, et je rencontre donc un nouveau problème:Code:
2
3
4
Un problème de linkage apparemment...
Une idée ? J'ai ajouté un #include <list> pour pouvoir utiliser la liste.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)
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...)
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++
@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
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)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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.
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.Citation:
Envoyé par Pierre Dolez
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>...
Rassurez-vous, moi aussi.Citation:
std::list<Bomb*>::iterator it=bombs_.begin() , j'ai du mal à comprendre comment ça fonctionne...
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.
Je pense que c'est plus facile à comprendre.Code:
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
Au point de vue performance je crois que c'est imbattable.
Mais, là c'est plus du C que du C++ :cry:
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.
Bon, on va commencer par le commencement:Citation:
Envoyé par Doudoupe
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
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 ::.Code:
2
3
4
5
6
7
8
Je ne peux donc déclarer un instance de Imbriquee que sous une forme de
Lorsque l'on écrit un code proche deCode:MaClass::imbriquee obj;
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.Code:std::list<Bomb*>::iterator it;
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
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 ;)Code:for(std::list<Bomb*>::iterator it=laliste.begin(); it!=laliste.end(); ++it)
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
Cela pourrait pourtant encore être améliorer, au moins en terme d'écriture, sous la forme deCitation:
Envoyé par Pierre Dolez
(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:)Code:
2
3
4
5
6
7
8
9
10
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)
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.
Mon intervention était surtout faite pour attirer l'attention de Doudoupe sur le fait qu'il manquait "quelque chose" :DCitation:
Envoyé par Pierre Dolez
J'espérais quelque part en effet que tu pensais aussi aux parties manquantes :D
Pas vraiment une question, mais plutôt une remarque:Citation:
D'autres questions?
Je suis à ta disposition.
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 ;)
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.
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.Citation:
Envoyé par Pierre Dolez
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.
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.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.
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:
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:
2
3
4
5
6
et cela permet une utilisation tout à fait transparente pour l'utilisateur:Code:
2
3
4
5
6
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19