Bonjour,

Je m´entraine aux listes chainées, mais je rencontre quelques petit problème.

d´abord, si j´ai une structure ID_List
et une variable
ID_List *NextID
pour acceder au membre de NewtID, il faut utiliser

• NextID->ID

ou bien
NextID->ID

La deuxième solution fonctionne, mais je ne comprend pas pourquoi.

Haaaaaaaaa, les pointeurs... un cap difficile pour bcp de personnes.

ID_List* NextID;
if(NextID!=NULL) / /Pour la bonne habitude
{
NextID->ID = truc; / /Correct
( *NextID).ID = truc;//Correct ( meme sans les ( ) )
( *NextID)->ID = truc; / /Erreur
}

NextID est un pointeur sur une structure, type ID_List*.

• NextID est une structure pointée.

NextID->ID point sur la variable ID tout comme ( *NextID).ID. C´est deux facon differente pour dire la meme chose.

Mais bon, les livres parlent surement mieux que moi

merci beaucoup, c´était un point mystérieux pour moi.

Ou est passé le fond d´écran de Kelios sur le sujet =)

ah oui, c´est donc kelios, je me souvenais de ce truc, mais je n´avais pas réussi à le retrouver vu que je ne savais plus qui l´avait fait.

http://redotror.free.fr/LinkedList.jpg

merci, maintanant que je sais que c´est kelios, ca a été facile de le retrouver, mais bon, son topic était linkedlist alors en cherchant liste chainé, on avait pas beaucoup de chance. Comme quoi, faire des topic explicite c´est important...

https://www.jeuxvideo.com/forums/1-31-8251082-1-0-1-0-0.htm

pour le topic.

a ce propos, kelios écrit :
struct Element
{
struct Element* Prochain;
int Valeur;
};

struct Element* Prochain;
est équivalent à
Element *Prochain;
non ?

Kelios écrit en C dans son exemple.
En C, tu est obligé d´utiliser " struct Element", alors qu´en C++, tu peux te contenter de " Element".
Pour éviter ceci, en C tu peux faire :

struct Element_
{
struct Element_* Prochain;
int Valeur;
};

puis :

typedef Element_ Element;

Ou plus concis :

typedef struct Element_
{
struct Element* Prochain;
int Valeur;
} Element;

( mais il faut laisser Element_ pour pouvoir déclarer le pointeur ) .

Et oui, ces noations sont équivalentes en C++ ( mais pas en C ) qui ne reconnais, selon la norme ANSI, que la première forme ) .

OOPS : Erreur :

typedef struct Element_
{
struct Element_* Prochain;
int Valeur;
} Element

C´est bien que tu fasses les listes chainées, ça donne une bonne notion d´algorithmique
Bon, je te laisse les finir, et apres, si tu veux, je te parlerai de ce qu´on appelle les . .. ( je ne dis pas le mot tout de suite), qui sont des listes chainées standard incluses dans tous les compilateurs C++, et oui, ça existe déja dans ton compilateur, lol ! !
un petit #include, et ça roule

Bon, allez, on en reparlera plus tard

c´est assez visieux de ta part ça JYY !

en fait, c´est toujours pour mes histiore de DLL ( j´avais un peu arrété à cause du bac), j´ai trouvé que les listes chainées étaient la manière la plus simple pour gérer la mémoire.

mais je ne sais pas du tout si ça va marcher, parce que je ne sais pas comment Windows gère les DLL et la mémoire entre les différent appel. je vais commencer a faire des test sur ce sujet.

A ce propos, une question stupide : où faut-il déclarer des variables pour qu´elle soit visible au niveau du projet ( dans tous les fichiers . cpp). Car quand je déclare des variable dans un fichier . h , si je l´inclue dans plusieurs fichiers le compilo fait une erreur au linkage.

je voulais dire vicieux bien entendu.

bon, j´ai fini la gestion des utilisateur de la DLL :
http://perso.wanadoo.fr/sectionpc/sectionbasic/programmes/linkedlist.htm
c´est le code qui s´en occupe.

Tout ça pour dire, que maintenant que ça marche, c´est ce code que j´utiliserai et donc pour ma culture, je ne refuserai pas des indications quand à la bibliothèque à inclure pour utiliser les listes chainées.

google vite fait :

http://www.game-lab.com/?p=viewtut&id=7&l=1#part4

Chapitre STL

merci,

en fait, on avait l´impression que jyy se fesait une joie de m´expliquer ( enfin, de me mettre sur la voie) c´est pourquoi je n´avais pas trop cherché.

bon, mais j´ai trouvé un site avec des références plus précise, et, pour ce dont j´avais besoin, je pense qu´une petite implémentation personnel est tout a fait suffisante et bien plus gratifiante que d´utiliser la très performante certe mais aussi complexe librairie standard.

en effet, c´est bien les STL

j´ai un exemple sur mon site si tu veux :

http://www.fvirtman.fr.st

rubrique info/progs/tutoC++
chapitre D.
mais c´est loin d´etre fini

" je pense qu´une petite implémentation personnel est tout a fait suffisante et bien plus gratifiante que d´utiliser la très performante certe mais aussi complexe librairie standard"

Ne réinvente pas la roue à chaque fois cependant : la STL est une source sûre de composants éprouvé et performant. Certains peuvent paraitre complexes, mais dans une optique de maintenance de projet, il est souvent plus aisé d´avoir recours à ce type de composants.
On ne sait jamais jusqu´où un projet peut mener

merci pour les réponses, il faut absolument qu´un jour je lise tout le cours de jyy, mais j´ai jamais trouvé le temps.

c´est vrai que la STL ou autre librairie est super pratique et qu´on peut gagner énormément de temps à l´utiliser, mais pour l´instant, je programme essentiellement pour apprendre à programmer ( en tout cas en C++), et dire je l´ai fait, ce qui n´est pas le cas de la STL !

Il est vrai que j´aime également pouvoir dire une fois le projet terminé : " c´est moi qui ai tout fait".
Cependant attention, car devoir tout reconstruire mène parfois à l´abandon du projet, faute de motivation en raison de l´absence d´un résultat encourageant rapidement.
Mais dans une optique d´apprentissage, la démarche est très bénéfique, d´autant plus que la réutilisation logiciele permettra de faire à nouveau usage de ces composants dans les projets futurs.
Reste que dans un contexte de performance, mis à part certains cas ou on a la possibilité de restreindre l´algorithme à un ensemble ( cosinus par exemple ) , il est préférable d´avoir recours à la STL...

lag-it > tout a fait !
je me rappelle, en cours, on m´a demandé de programmer des listes chainées, toute sortes de trucs comme ça, bon, j´y ai fait.

Mais maintenant, des que j´ai besoin de ça, je ne vais pas chercher mon vieux TP, c´est STL direct !
car derriere, tu as 50000 algos sympas !

Suis je vraiment le seul à trouver la STL LOURDE?
Vraiment, je trouve ça vraiment une librairie-boulet...

C´est lourd, trop généraliste ( pas optimisé pour ton cas à TOI...) et gonflé de code à coucher dehors, savez qu´à regarder les " header-source(?)" des différents composants de la STL pour voir...

Consommation abusive du POO, surutilisation des templates ( à mon avis), enfin bref, ça fait pas dans la dentelle...

Et ce, sans compter que c´est pas n´importe quelle classe qui peut être STLisé! Hé oui, y´a des restrictions, des prérequis au niveau des classes! Qui a dit boulet? Moi... ( suis-je vraiment le seul?)

Et quand tu débug, c´est pas vraiment un cadeau. Certes, toute la STL doit être pratiquement sans faille, mais que ce passe-t-il lorsqu´il s,agit de ta classe STL-isée qui a un problème quelconque?

Ben oui, tu le débuggue, et tu te retrouve vite à devoir jongler dans ton code, mais avec un boulet en arrière, la STL.

Ici bien sur je parle de ma propre expérience, donc je sais pas si c´est votre cas, mais pour moi:
La STL a beaucoup d´avantages,
La STL a aussi beaucoup de désavantages,
Et à mon avis Désavantages de la STL > Avantages de la STL.

Enfin bref, moi la STL, pour les gros projets, non merci.

T´es bien plus à l´aise dans ton code...

Mon conseil? Fais toi ta propre STL ( en plus spécialisé pour tes trucs, cepandant):
-Tu apprend tout comment ça marche.
-Le gain didactique est énorme ( voir les commentaires dans les posts précédents).
-Tu peut la réutiliser tout comme la STL si tu l´as bien conçu.
-C´est une réalisation dont tu pourra être fier et qui te sera utile tout le temps.
-Ça sera bien meilleur pour toi que la STL ( quoique pour les autres ça sera pas nécessairement le cas).
-T´es pas obligé de refaire toute la STL, seulement ce que tu trouve vraiment utile pour toi...
-Gros avantage: modifiable à guise, tu pourra continuellement l´améliorer et l´adapter avec le temps quand tu trouvera les modifications utile voire nécessaire : la librairie évolueras avec toi.
-Je vois pas grand chose d´autre.

Kelios
---------