Mal a la tete avec liste chainée d'objet

Salut a tous...

Voila je suis en train d'essayer de creer une liste doublement chainée d'objet et j'avou que je commence a avoir un peu mal a la tete la :p

Mon objet n'est constitue que de TCHAR (et oui en plus je suis en UNICODE :p ). Voila la déclaration de ma liste (que j'ai aussi creer en tant qu'objet)

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

class CListeProduit { private: CProduit m_valeur; class CListeProduit *m_Prec; class CListeProduit *m_Suiv;   public: void Insert (CProduit p_ajout); void Retirer (); void Rechercher (TCHAR* p_code); void Afficher (); }   Jusque la pas de probleme... C'est lors de l'ajout que ca coince...   void CListeProduit::Insert (CProduit p_ajout) { CListeProduit *nouveau = new CListeProduit;   nouveau->m_valeur = p_ajout; nouveau->m_Prec = *this; nouveau->m_Suiv = NULL;   m_Suiv = *nouveau;   this = nouveau; }

---

La, impossible de compiler. Pas d'operateur qui prend en charge ma class pour =.

Quelqu'un pourrait m'aider a demeler le meli melo de pointeur que j'ai dans la tete ?

Merci d'avance


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

C'est quelle ligne qui pose problème ?
Pourquoi n'utilises-tu pas la STL ? Les listes doublement chaînées sont déjà implémentées !

Les lignes qui posent problemes sont... Toutes celles ou je fais une affectations :D

nouveau->m_Prec = *this;
nouveau->m_Suiv = NULL;

m_Suiv = *nouveau;
this = nouveau;


Et si il existe deja quelque chose qui marche bien ca pourrait peut etre m'interesse :p

Meme si je prefererai reussir a le coder moi meme :Ego Inside:

Hum la STL c'est bien connu pour éviter les maux de tete :)

regarde de ce coté là :

http://www.sgi.com/tech/stl/List.html

notamment du coté de push_front() et push_back()

essayer la STL c'est l'adopter !


NhyMbuS

Sinon concernant tes erreurs, tu essayes d'affecter des CListeProduit à des CListeProduit*. Il ne faut pas déréférencer tes pointeurs.

La réaffectation de this pose problème aussi. C'est impossible et si tu y réflechis bien, c'est logique (c'est d'ailleurs bien pour cela que this est const).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void CListeProduit::Insert (CProduit p_ajout) { CListeProduit *nouveau = new CListeProduit;   nouveau->m_valeur = p_ajout; nouveau->m_Prec = this; nouveau->m_Suiv = NULL;   m_Suiv = nouveau;   // this = nouveau; Outch ! }

---

Et... de manière générale tu t'y prends mal. Idéalement il faut séparer les tâches : l'objet liste ne doit pas être un noeud de celle-ci, mais simplement pointer vers le premier (et le dernier pour une liste double). Il y a pas mal de posts qui parlent de design de liste chaînées, tu peux peut-être trouver plus de détails avec la recherche avancée.

Les autres problemes j'avais trouvé... Mais c'est vrai qu'en ayant réfléchi 2s... la réaffectation de this me choque moi meme...

Merci du coup de main. Je vais essayer de trouver d'autre exemple pour que ca marche :)

Bon apres mur reflexion et une illumination de ma part, j'ai décidé de me lancer dans la création d'un arbre binaire. En effet, je risque d'avoir un grand nombre de données a stocke (jusque 200k lignes) mais je ne peux pas utiliser de bdd... Vive les pockets pc au rabais :p

Donc en attendant je me suis dit qu'un arbre binare serait mieux car recherche faciliter..

Voila la dec.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class CListeProduit { private: CProduit m_valeur; class CListeProduit *m_gauche; class CListeProduit *m_droite;   public: void Insert (CProduit p_ajout); void Retirer (); void Rechercher (TCHAR* p_code); void Afficher (); CListeProduit();   };

---

Et l'ajout.

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

void CListeProduit::Insert (CProduit p_ajout) { if (m_valeur.GetGenCode() != TEXT("")) { if (wcscmp(m_valeur.GetGenCode(), p_ajout.GetGenCode()) > 0) { if (m_gauche != NULL) m_gauche->Insert(p_ajout); else m_gauche = new CListeProduit; m_gauche->Insert(p_ajout); } else { if (m_droite != NULL) m_droite->Insert(p_ajout); else m_droite = new CListeProduit; m_droite->Insert(p_ajout); } } else m_valeur = p_ajout;     }

---

Ca compile parfaitement. Toutefois, je ne vais pas pouvoir le tester avant un petit moment... Donc si vous pouviez me dire si vous voyez es trucs faux dedans... Je ne suis pas sur de moi au niveau de la création des branches surtout...


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

Si tu veux rechercher un élément en fonction de son identifiant (ici une chaîne), std::map sera parfait.

Et s'il-te-plaît, :tagcode:

Bon le je vais exploser... J'ai essayer d'installer la STL. J'ai bien ajouter le dossier dans VS. Mais il ne trouve pas... iostream.h !

J'ai peut etre oublier de preciser que je dev pour un produit Win CE et que je travailles donc sur EVS. Est il possible que iostream ne soit pas compatible Win CE ?

Et pour les balises... je n'étais pas au courant (j'entends deja les mais c'est marqué dans les regles :p) et je le ferai maintenant :)

Tu n'as pas à installer la STL, elle vient normalement avec ton compilo quelqu'il soit. Concernant iostream.h, c'est normal, depuis la norme de 98 c'est iostream sans .h (voir la FAQ pour plus de détails).

J'ai reussit a ajouter iostream. Mais chez moi il a fallut que je mette #include <iostream.h>.

Mais la ou je ne comprends plus rien... C'est qu'il ne veut toujours pas que j'utilise le namespace... Des que j'essaie de l'apeller comme la :

Code:

---

1 2 3 4 5 6

switch (message) { case WM_INITDIALOG: std::ifstream fichier( "fichier.txt" );

---

Il me dit que std n'existe pas...

[edit]

En retirant le std:: il ne bloque plus dessus ( a parement il n'y a vais pas besoin de specifier le namespace...)... Mais maintenant je me retrouve avec des unresolved external symbol...

Quel est la lib relier a iostream ? Parce que generalement les unresolved external c'est que l'on a pas inclu la lib dans le projet.

J'ai lu a divers endroit qu'il fallait modifier les propriétés du projet (au niveau de use runtime lib) mais je ne peux pas (parce que projet Win CE).

Quelqu'un aurait une idée ?

Il n'y a pas de librairies a linker.

Code:

---

1 2 3 4 5 6 7 8

#include <iostream> using namespace std;   int main(void) { cout << "Coucou" << endl; return 0; }

---

Code:

---

g++ test.cpp -o test

---

Si tu veux utiliser les listes

Code:

---

#include <list>

---

utilises des pointeurs, ca t'evitera de recréer des instances de CProduit à tout va

Le probleme.. C'est que si je fais

Code:

---

1 2	using namespace std;

---

Il me dit que std n'est pas un namespace...

Voila mes déclarations à l'initialisation..

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

// Logistik.cpp : Defines the entry point for the application. //   #include <stdio.h> #include <windows.h> #include <windowsx.h> #include <commctrl.h>   #include "stdafx.h" #include "Logistik.h" #include "Functions.h" #include "Inventaire.h" #include "audiocapi.h" #include "LPro.h" #include <ScanCAPI.h> #include <fstream.h> #include <iostream.h>   using namespace std;

---

Et juste avec ca il ne veut pas compiler.

Si j'essaie de ne pas declarer le namespace, ca ne plante pas. La compil se passe bien. Mais lorsque je fais l'édition des liens, il me sort des nresolved pour chaque fonction apartenant au std que j'utilise...

De deux choses l'une :

1- Ton compilo est vieux ou limité (possible dans ton cas) : en-têtes standards avec .h et pas d'histoire de namespace std.

Code:

---

1 2	#include <fstream.h> fstream f;

---

2- Ton compilo est suffisamment récent : en-têtes standards sans .h et utilisation de l'espace nommé std.

Code:

---

1 2	#include <fstream> std::fstream f;

---

Tu as quelle version de VS ?
Tu peux vérifier dans ton aide que le namespace est bien défini pour ta plateforme - il n'y a pas de raison pour que ça ne soit pas le cas, mais bon... -

je suis sous Embedded VS 4.0, et non je n'ai pas le choix des outils donc je ne peux pas changer :p.

Visiblement il faut que je conserve le .h et que je ne declare pas le namespace. Dans ce cas la ca compile normalement.

Mais lorsque je fais l'édition des liens, je me tape des unresolved external symbol sur les fonction que j'utilises (pour l'instant ifstream je n'ai pas pu en rajouter d'autre étant donné que ca ne marche deja pas).

Ce qui me parait bzarre c'est que j'ai quand meme deja eu a utiliser iostream pour bien d'autre projet (pour pc normaux ceux la) et que je n'ai jamais eu de probleme... Je me demande si ce n'est pas le fait que je dev pour Win CE qui pourrait poser probleme... Mais ca me paraitrait bizarre parce que iostream est tout de meme une des lib de base...

Si quelqu'un a une idée parce que la sincèrement... Je me sens un peu perdu :(

Je ne connais pas cette version, mais elle est datée de quelle année ?
Il te faut peut-être ajouter un fichier .lib dans l'édition des liens...

J'y avais penseR... Mais pas moyen de trouver a quelle lib correspond iostream...

Mais ce qui me parait bizarre aussi.. C'est que le chemin vers iostream.h n'"tait pas de base dans la liste des chemins vers les includes. Je l'ai rajoute tout comme celui de slib.

Je suis en train de me demander si par hasard ca ne serait pas l'install de VS qui serait foireuse... Ce n'est pas moi qui l'ai faite et je ne sais pas si elle aurait pas été faite a l'arrache...

Je vais essayer de tout desinstaller et reinstaller des fois que...

Il est tout à fait possible que ta version de Visual C++ ne soit pas configurée, comme l'est la version toolkit (je crois). Dans ce cas il faut lier avec libc.lib (ou libcmt, libcd, libcmt selon l'option de compilation choisie).

Sinon c'st clair utilise "std::list<>" ou "std::map<,>"
Ultra simple à utiliser. Comme l'a dit déjà quelqu'un : l'essayer c'est l'adopter...

Si tu utilise les anciens header de la stl (*.h) ils ne sont PAS dans un namespace

Si tu veux utiliser std:: il faut utiliser les header SANS .h

Citation:

---

Envoyé par fd

Si tu utilise les anciens header de la stl (*.h) ils ne sont PAS dans un namespace

---

Ils ne sont pas tout court.
Tout variait d'un fournisseur à l'autre. Et généraliser n'est pas vraiment possible.