#include <iostream>
using namespace std;

struct Element
{
  int valeur;
  Element *next;
};

struct linked_list
{
  Element *first;
};

linked_list *constructeur_list()
{
  linked_list *liste=(linked_list*)new(sizeof(linked_list));
  return liste;
}

Voici ce que la console m'affiche :error: expected a type

Lu'!

Qu'est ce que tu suis comme cours pour aboutir à un code comme ça ? Là ton code en gros c'est du C, il faut juste mettre "malloc" à la place de ton mot clé "new" (qui ne s'utilise pas comme ça) et retirer ton include de iostream et ton "using namespace std" (qu'on préfère ne même pas mettre en C++). Sérieusement, quitte à faire du code qui est fondamentalement de C, fais du C.

Salut, pourquoi tu te prend la tete a faire une liste chainer en moins bien que la STL ?

Utilise https://en.cppreference.com/w/cpp/container/list 

Mais je te conseille plus https://en.cppreference.com/w/cpp/container/vector 

Comme mes petits camarades, std::list et peut être même si on commence à causer performances std::vector...

Les performances de nos machines sont telles, que souvent, ce qui se ferait intuitivement sur une liste chaînée, se fera en fait sur un tableau dynamique (un std::vector en C++), juste parce que l'analyse des besoins va montrer qu'en fait l'aspect liste n'apporte rien par rapport à un tableau. Le tableau a par ailleurs une caractéristique tout à fait considérable, il garantit la contiguïté des données en mémoire et ça c'est super pour la gestion mémoire de très bas niveau, c'est ce qu'on appelle le cache friendly: le processeur charge les données dont il a besoin dans sa mémoire cache et fait sa tambouille, mais entre un traitement entre de la donnée en cache et de la donnée en RAM, tu as un facteur 10 (en faveur du cache évidemment), si jamais tu dois aller la chercher sur un disque dur (SSD ou HDD peu importe), tu passe à un facteur d'environ 1000000...

class Doublelist{
  private:
    typedef struct node{
      int data;
      node *next;
      node *prev;

    } * nodePtr;

    nodePtr curr;
    nodePtr temp;
    nodePtr head;

  
  public:
    Doublelist();
    void Addnode(int addData);
    void PrintList();
};

#include <iostream>
#include "Doublelist.h"
#include <cstdlib>
using namespace std;



Doublelist::Doublelist()
{
  head=NULL;
  curr=NULL;
  temp=NULL;
}

void Doublelist::Addnode(int addData)
{
  nodePtr n=new node;
  head->prev=n;
  n->prev=NULL;
  head=n;
  n->data=addData;
}

void Doublelist::PrintList()
{
  curr=head;
  while(curr!=NULL)
  {
    cout<<curr<<" ";
    curr=curr->next;
  }
}

int main() {
  Doublelist Liste;
  Liste.Addnode(5);
  Liste.Addnode(2);
  Liste.Addnode(7);
  Liste.PrintList();
}

Dans Addnode, quand ta liste est vide, tu utilises head (ligne 18) alors qu'il vaut NULL. Il ne pointe pas sur un maillon valide. (Il faut revoir ton algo).

Pourquoi mettre les variables curr et temp en donnée membre de la classe ? 

Tu n'as pas le droit d'utiliser la STL à l'université ? Tu fais de l'archéologie expérimentale? 

A titre informatif, la SL fait partie intégrante du langage C++ depuis un peu plus de 20 ans, la première mouture de la norme date de 1998... Il serait peut être temps que ton incapable de prof se sorte les doigts du cul et mette son cours à jour! 

-
Edité par int21h 25 août 2019 à 0:16:00

Il faut bien passer par une phase d'apprentissage des listes chaînées pour en assimiler le concept. Çà peut être intéressant également pour enchaîner sur l'implémentation des arbres.

Parce que de ce que je comprends des réponses précédentes, il faudrait passer par un autre langage que le C++ pour faire un TP sur l'implémentation des listes chaînées sous prétexte qu'elles existent déjà en C++?

L'implémentation "à la main" de la liste chaînée n'a peut-être ici qu'un but pédagogique, et si le prof fait bien son travail, il devrait enchaîner avec l'utilisation des listes de la SL.

-
Edité par zoup 25 août 2019 à 10:24:47

Non, tu as mal compris ses propos.

Implementer des listes chainee a but pedagogique en C++ ce n'est pas un mal, mais encore faut-il que le C++ soit maitrisee et propre.

Ici, il y a des fuites de memoires, et une mauvaise utilisation des objets.

Il y a d'abord un travail sur le C++ a faire avant d'implementer ses containers, et ici ce n'est pas fait.

Bonjour,

Avant de passer à la STL, il va falloir désapprendre de nombreuses choses:
- Utilisation dangereuse de new. utilisation de new sans destructeur, sans delete, et une fois ceux-ci ajoutés essaie d'ajouter une dernière ligne à ton main la simple ligne Doublelist Liste2 = liste; pour voir les dégâts (incompatibilité avec les exceptions, constructeurs et opérateurs de copie et de transferts non valides)
- utilisation de using namespace dans un code. Cette directive a été créée pour des problèmes de compatibilité de code des années 80 dans des structures des années 90. Serais-tu en train d'écrire du code des années 80 à compiler en 1990?
- Ce qui m'interpelle le plus c'est d'avoir placés le variables curr et temp dans la classe. Si on a appris ce qu'est une classe on ne peut pas commettre ce type d'erreur grave. Vous n'avez donc pas appris cela.
- et autant il y a des listes chaînées dans mon cours C, autant je les ai ôtées du cours C++ car il faut apprendre à jongler avec les pointeurs en C, et apprendre à les éviter en C++.

Sincèrement, je crains pour toi, très fortement que ton prof n'ait jamais appris le C++.

zoup a écrit:

Il faut bien passer par une phase d'apprentissage des listes chaînées pour en assimiler le concept. Çà peut être intéressant également pour enchaîner sur l'implémentation des arbres.

Hé bien, non, justement!

Les notions de pile, de file, de liste et autres arbres en tout genre sont avant tout des notions purement conceptuelles, dont l'énorme intérêt tient à la comparaison de la complexité des différents comportements que l'on est en droit d'en attendre.

zoup a écrit:

Parce que de ce que je comprends des réponses précédentes, il faudrait passer par un autre langage que le C++ pour faire un TP sur l'implémentation des listes chaînées sous prétexte qu'elles existent déjà en C++?

Ce n'est pas parce qu'elles existent déjà en C++ que ce TP n'a aucun sens : c'est parce que C++ entre dans la catégorie des langages à exceptions!

Autrement dit, si "quelque chose" -- comme l'allocation de mémoire pour un nouveau noeud, par exemple -- vient à foirer, C++ va lancer un comportement qui va quitter la fonction en cours et remonter la pile d'appels jusqu'à trouver un endroit (s'il existe) dans le code où le problème pourra être traité.

Un TP qui ne prendrait pas cette possibilité en compte ne pourrait en aucun cas être considéré comme "correct".  Un langage qui n'utilise pas les exceptions (comme C, par exemple) serait dés lors beaucoup mieux adapté à ce genre de TP, même si le risque de l'allocation de mémoire échoue devrait également être pris en compte pour pouvoir considérer le TP comme "correct".

zoup a écrit:

L'implémentation "à la main" de la liste chaînée n'a peut-être ici qu'un but pédagogique, et si le prof fait bien son travail, il devrait enchaîner avec l'utilisation des listes de la SL.

Si le prof t'apprenait le C, j'aurais été tout à fait d'accord avec toi, car la gestion dynamique de la mémoire et la compréhension correcte de la notion de pointeur prennent des places prépondérantes dans le langage.

Mais en C++?!!!??? Quel pourrait être ce but pédagogique ?

Si le but est de te familiariser avec les notions d'allocation dynamique de la mémoire et de pointeurs, ton prof fait du grand n'importe quoi, car il n'y a que dans le cadre d'une hiérarchie de classes polymorphe que ce genre de chose a réellement du sens : entre

• les  références qui ont le bon gout de devoir être associée à un objet existant
• les collections de la STL qui ont le bon gout de gérer la mémoire correctement
• les pointeurs intelligents qui ont le bon gout de veiller à libérer la mémoire allouée dynamiquement "en temps opportun"

il n'y a plus aucune raison d'avoir recours au pointeurs pour autre chose que l'utilisation de classes polymorphes.  Même la possibilité que quelque chose puisse "ne pas exister" est couverte par les fonctionnalités du C++.

En 2005, à l'époque où j'ai décidé de valider mes connaissances en programmation par un graduat (et alors que l'approche historique était encore largement répandue, faute d'alternative), j'engueulais déjà mon prof à chaque fois qu'il avait  recours à  une allocation dynamique de la mémoire alors qu'il y avait moyen de faire autrement grâce à la STL. 

C'était devenu une sorte de jeu : "vous savez monsieur que, si vous utilisez (std::vector, std::striing, std::map, .... ) vous aurez beaucoup plus facile à faire le taf (regardez : XXX lignes en moins), avec un taux de garantie bien supérieur?".

Lors des derniers cours, mon prof m'a demandé comment il pourrait réorganiser son cours pour, justement, présenter les chose sous une approche "moderne", et je me suis empressé de lui faire un plan de base (j'espère qu'il l'a mis au point ). 

Depuis, bien de l'eau a coulé sous les ponts, et le comité pense tout doucement à proposer un plan d'apprentissage finalement très proche de celui que j'avais dressé à l'époque.

Il faut bien se dire que C++ a énormément évolué depuis 2011.  Il serait peut-être temps que les profs se décident à  dépoussiérer un cours qui était déjà obsolète depuis longtemps bien avant, tu ne crois pas ?

Est ce qu'un prof qui enseigne Java va imposer à ses élèves, l'implémentation d'une liste chaînée, bien sûr que non, il va  à a la place , leur proposer un exercice dont le propos sera d'utiliser l'implémentation fournie par la bibliothèque standard du langage Java (ce qui est bien plus intelligent). Pourquoi les soit disant "profs de C++"  ne font pas pareil? 

• 1 Ils sont incompétents, en 20 ans, ils n'ont pas été foutus, d'adapter leurs cours à la norme.
• 2 en plus d'être incompétents, (Cf 1), ce sont des branleurs, qui n'ont pas fais le moindre effort pour adapter leur cours au cours des 20 dernières années. 

Aucune pitié pour ces branleurs, leur place est à Pole Emploi, pour des boulots de balayeur et encore, je ne suis même pas sûr qu'ils aient le niveau...

class maillon
{
  int val;
  maillon * succ;
  maillon * pred;

  public:
    maillon();
    ~maillon();
};

class Liste : public maillon
{
  maillon *tete;
  maillon *queue;

  public:
    Liste();
    ~Liste();
    bool Vide();
    void InsertionEnTete(int x);
    void InsertionEnQueue(int x);
    int Recherche(int x);
    void Suppression(int A);
};

#include <iostream>
#include "liste.h"
using namespace std;


Liste::Liste()
{
  tete=NULL;
  queue=NULL;
}

bool Liste::Vide()
{
    if(tete == NULL and queue==NULL)
    {
      return true;
    }
    else return false;
}

void Liste::InsertionEnTete(int x)
{
  if(tete==NULL)
  {
    maillon *n=new maillon;
    tete=n;
    tete->val=x;
  }
}

-
Edité par Anonyme 25 août 2019 à 19:20:32

koala01 a écrit:

Hé bien, non, justement!

Les notions de pile, de file, de liste et autres arbres en tout genre sont avant tout des notions purement conceptuelles, dont l'énorme intérêt tient à la comparaison de la complexité des différents comportements que l'on est en droit d'en attendre.

Tout le monde ne conceptualise pas avec la même facilité. Je me rappelle avoir fait des mois d'algo avec crayon gomme papier avant de toucher à un ordi. C'était peut-être formateur mais ce n'était pas drôle. Je pense que l'introduction de TP permet d'une manière générale de faciliter l'assimilation des différents concepts enseignés.

koala01 a écrit:

Ce n'est pas parce qu'elles existent déjà en C++ que ce TP n'a aucun sens : c'est parce que C++ entre dans la catégorie des langages à exceptions!

Là il s'agit je pense d'enseigner les bases de l'algo et des différentes structures de données. C++ peut très bien servir de support car l'apprentissage de ce langage n'est pas forcément la finalité recherchée.

koala01 a écrit:

Si le prof t'apprenait le C, j'aurais été tout à fait d'accord avec toi, car la gestion dynamique de la mémoire et la compréhension correcte de la notion de pointeur prennent des places prépondérantes dans le langage.

Mais en C++?!!!??? Quel pourrait être ce but pédagogique ?

De ne pas avoir à apprendre un langage de plus. Rien n'oblige à utiliser le paradigme objet en C++

Pour le reste, je suis entièrement d'accord avec toi si le but est vraiment d'apprendre la programmation objet en utilisant les ressources mises à la disposition du langage, à savoir la SL principalement pour le C++, alors oui, on doit utiliser les classes qui vont bien. Mais, je le répète, est-ce bien le cas ici?

-
Edité par zoup 26 août 2019 à 1:50:01

zoup a écrit:

Tout le monde ne conceptualise pas avec la même facilité. Je me rappelle avoir fait des mois d'algo avec crayon gomme papier avant de toucher à un ordi. C'était peut-être formateur mais ce n'était pas drôle. Je pense que l'introduction de TP permet d'une manière générale de faciliter l'assimilation des différents concepts enseignés.

Je crois sincèrement que cela dépend de la manière dont le cours d'algo est donné, et, principalement de deux choses:

1. la représentation que l'on fait de l'algorithme
2. la capacité de celui qui donne le cours à se faire aussi bête qu'un ordinateur

J'ai, pour ma part, eu la chance d'avoir un prof qui

Nous a parlé du flowchart juste assez longtemps que pour que l'on se rende compte de ses limites (en ce qui concerne les boucles imbriquées, principalement) avant de passer au Nassi-Schneiderman (et au jackson pour traiter les ruptures), et qui n'hésitait jamais à se mettre à la place de l'ordinateur pour voir comment il réagirait à une instruction donnée.

Du coup, j'ai adoré ce cours, et il m'arrive très souvent de faire mon petit algo avant même de me mettre à l'écriture du code

zoup a écrit:

Là il s'agit je pense d'enseigner les bases de l'algo et des différentes structures de données. C++ peut très bien servir de support car l'apprentissage de ce langage n'est pas forcément la finalité recherchée.

Justement, un algorithme est -- par nature -- totalement indépendant du langage envisagé!  L'écriture du code en lui-même, quel que soit le langage, n'est jamais qu'un long et fastidieux travail de traduction et de dactylographie, une fois que l'algorithme est décidé

Si je reconnais tout l'intérêt qu'il peut y avoir à faire exécuter un algorithme donné dans un langage quelconque, l'apprentissage des concepts devrait être totalement séparé de l'apprentissage du langage

zoup a écrit:

De ne pas avoir à apprendre un langage de plus. Rien n'oblige à utiliser le paradigme objet en C++

Mais, justement, tu n'as  besoin d'avoir recours à absolument aucun langage pour apprendre les différents concepts et l'algorithmie.  Pas même à un seul, quelles que soit les possibilités qu'il offre

Que tu apprenne l'UML ou n'importe quelle manière de représenter un algorithme, tu n'as a absolument aucun besoin de faire référence à un langage quelconque, vu que, par nature, tes schémas UML, flowchart ou nassi-schneiderman te permettent de représenter ... la vue de l'esprit qui correspond à des concepts.

koala01 a écrit:

Je crois sincèrement que cela dépend de la manière dont le cours d'algo est donné, et, principalement de deux choses:

1. la représentation que l'on fait de l'algorithme
2. la capacité de celui qui donne le cours à se faire aussi bête qu'un ordinateur

J'ai, pour ma part, eu la chance d'avoir un prof qui

Nous a parlé du flowchart juste assez longtemps que pour que l'on se rende compte de ses limites (en ce qui concerne les boucles imbriquées, principalement) avant de passer au Nassi-Schneiderman (et au jackson pour traiter les ruptures), et qui n'hésitait jamais à se mettre à la place de l'ordinateur pour voir comment il réagirait à une instruction donnée.

Du coup, j'ai adoré ce cours, et il m'arrive très souvent de faire mon petit algo avant même de me mettre à l'écriture du code

Entièrement d'accord pour ma part, lorsque je veux faire passer des notions élémentaire d'algo (tests, boucles, etc) je fais un mini jeu de rôle avec mon interlocuteur dans lequel je joue le rôle de l'utilisateur et lui celui de l'ordinateur, dans lequel il n'a droit qu'à des instructions élémentaire et de mémoriser que le nombre de données que je lui accorde.

J'essaie de lui faire comprendre que pour ces algo élémentaire, il suffit d'appliquer le raisonnement humain mais en le décomposant en actions élémentaires au lieu de l'appliquer mécaniquement par la force de l'habitude.

Çà résout un certain nombre de problèmes et permet quand tout va bien de comprendre ce qu'un ordi est en mesure de faire et comment le lui faire faire.

koala01 a écrit:

Justement, un algorithme est -- par nature -- totalement indépendant du langage envisagé!  L'écriture du code en lui-même, quel que soit le langage, n'est jamais qu'un long et fastidieux travail de traduction et de dactylographie, une fois que l'algorithme est décidé.

Et bien justement, ce que j'essaie de faire comprendre que dans notre cas il ne s'agit pas d'un pur problème de C++. Donc quel est le problème à coder en C++ old style finalement?

koala01 a écrit:

Mais, justement, tu n'as  besoin d'avoir recours à absolument aucun langage pour apprendre les différents concepts et l'algorithmie.  Pas même à un seul, quelles que soit les possibilités qu'il offre

Que tu apprenne l'UML ou n'importe quelle manière de représenter un algorithme, tu n'as a absolument aucun besoin de faire référence à un langage quelconque, vu que, par nature, tes schémas UML, flowchart ou nassi-schneiderman te permettent de représenter ... la vue de l'esprit qui correspond à des concepts.

Ok, mais on en revient à ce dont je parlais plus haut: quid de la pratique? Si on veut tester son algo et le mettre au point, c'est quand même bien de le coder => il faut avoir recours à un langage.

> Donc quel est le problème à coder en C++ old style finalement?

S'embêter sur des détails de C++ qui n'apporte rien en compréhension de l'algorithme ni même en formation. Alors que C++ moderne offre plusieurs instruments qui rendent le code plus simple à écrire, avec moins de prise de tête pour un étudiant.

GlovedWoman a écrit:

> Donc quel est le problème à coder en C++ old style finalement?

S'embêter sur des détails de C++ qui n'apporte rien en compréhension de l'algorithme ni même en formation. Alors que C++ moderne offre plusieurs instruments qui rendent le code plus simple à écrire, avec moins de prise de tête pour un étudiant.

J'ai l'impression de reprendre mes explications depuis le début: tu estimes donc inutile de montrer au travers d'un TP la création et l'exploitation d'une liste chaînée basique?

Je comprends qu'un certain nombre de personnes puissent se contenter d'une présentation purement abstraite des différents conteneurs lors de l'apprentissage, mais pour ma part, un petit peu de pratique m'a toujours permis de bien ancrer les choses dans le concret et donc de les assimiler plus facilement.

Il serait intéressant de demander à des étudiants "standard" venant de suivre un cours sur les conteneurs de la SL d'expliquer quelles raisons les poussent à choisir std::list plutôt que std::vector pour un problème donné. Je reste persuadé que pour la majorité de ces étudiants, avoir mis un peu les pattes dans le "cambouis" leur sera bénéfique pour effectuer ce choix.

-
Edité par zoup 26 août 2019 à 16:01:03

On peut tout à fait conduire une voiture sans savoir comment ça marche. Il faut juste mettre du carburant quand elle en réclame !

PS : Ce qui est hallucinant dans ce sujet, c'est que l'on méprise l'auteur du sujet !

Mépriser est un peu exagéré. J'avais plutôt l'impression de prendre sa défense.

"On peut tout à fait conduire une voiture sans savoir comment ça marche. Il faut juste mettre du carburant quand elle en réclame !"

Bof. Permets-moi de ne pas partager ce point de vue.

Mais il y a peut-être un peu de flooding en effet. J'invite donc mominateur à se manifester pour reprendre le fil de sa discussion.

-
Edité par zoup 26 août 2019 à 16:29:30

Toujours là avec le même problème ma fonction "InsertionEnTete" et je ne comprend pas pourquoi mon professeur nous impose une classe comme cela (Liste et maillon) cela n'aurait pas été plus simple de faire seulement une classe Liste avec à l’intérieur une structure maillon ?

PS: Dans les fait je suis plutôt d'accord avec le fait que je ne comprend pas pourquoi on ne nous apprend pas ou du moins nous autorisés à utiliser les STL pour en prendre l'habitude dès le début. Mais je n'ai aucune légitimité d'en parler je ne suis qu'un débutant et je ne m'y connais pas en pédagogie .

-
Edité par Anonyme 26 août 2019 à 16:45:17

zoup a écrit:

Mépriser est un peu exagéré. J'avais plutôt l'impression de prendre sa défense.

Ça ne s'adresse pas particulièrement à toi. 

zoup a écrit:

J'invite donc mominateur à se manifester pour reprendre le fil de sa discussion.

Il l'avait fait mais votre discussion à continué comme s'il n'était pas là, et c'est cela que je trouve méprisant ! (C'est très fréquent sur le forum C++).

@mominateur 

Tu est parti un peu dans tous les sens, tu as posté trois code complètement différents. Le premier était quasiment du C. (Tu l'aurais fait en C et posé tes questions sur le forum C, ça aurai moins polémiqué, mais bon si tu dois doit le faire en C++).

Si tu dois faire deux classes, je ne crois pas que tu puisses faire hériter la classe liste de maillon. Pour en revenir à ma voiture, une voiture n'est pas un moteur, elle possède un moteur, ce n'est pas tout à fait pareil. 

-
Edité par rouloude 26 août 2019 à 18:03:06

@zoup : non, je ne dis pas qu'il ne faut pad réimplémenter une liste chaînée. Je dis que se casser la tête à gérer manuellement des nzw delete, ou pire des mallocs free, c'est inutile et ça détourne de l'exercice et de l'algorithmique.

C'est pas pour rien qu'on conseille souvent Python à ceux qui veulent apprendre à coder. C'est parce que c'est un langage où, globalement, y'a moins ces prises de tête techniques qu'on a en C++ (surtout old school).

D'où l'intérêt d'utiliser C++ moderne pour implémenter une liste chaînée. Pour ça, faut avoir des profs intelligents et à jour, mais c'est un autre débat.

-
Edité par Anonyme 26 août 2019 à 18:44:40

Mominateur a écrit:

Toujours là avec le même problème ma fonction "InsertionEnTete" et je ne comprend pas pourquoi mon professeur nous impose une classe comme cela (Liste et maillon) cela n'aurait pas été plus simple de faire seulement une classe Liste avec à l’intérieur une structure maillon ?

Bien sur que cela aurait été beaucoup plus simple, mais cela aurait surtout été beaucoup moins marrant .

Parce que, alors, il aurait dit adieux au problèmes d'accessibilité des données, et il n'aurait pas pus t'inciter à réfléchir aux différents moyens dont tu dispose pour les contourner .

rouloude a écrit:

Si tu dois faire deux classes, je ne crois pas que tu puisses faire hériter la classe liste de maillon. Pour en revenir à ma voiture, une voiture n'est pas un moteur, elle possède un moteur, ce n'est pas tout à fait pareil.

 Et tu as tout à fait raison : tu ne peux en aucun cas faire hériter ta classe liste d'une classe maillon, car cela n'aurait aucun sens au point de vue du LSP

Par contre, les solutions existent au problème:

Soit tu fournis des fonctions publiques qui permettent d'accéder au maillon précédant, au maillon suivant  et à la valeur représentée par le maillon, et d'autres qui permettent de modifier ces données le cas échéant (de bon gros getXXX et setXXX, bien lourds), mais on pourrait alors se poser la question de savoir pourquoi tu pris la peine de les placer dans l'accessibilité privée, si c'est pour quand même en arriver à fournir un accès "plein et entier" à toutes ces données;

Soit tu te dis que, l'un dans l'autre, il n'y a vraiment que la liste qui doit pouvoir accéder à ces éléments et que "le reste du monde" ne doit pouvoir faire que trois choses avec la notion de maillons, à savoir:

• accéder au maillon précédant (s'il existe)
• accéder au maillon suivant (s'il existe) et
• comparer deux maillons entre eux pour savoir s'il sont identiques

class Maillon{
public:
    Maillon() = default;
    Maillon * operator++(){
        return suivant;
    }
    Maillon * operator --(){
        return precedant;
    }
private:
    /* toute la magie se trouve dans la ligne qui vient
     */
    friend class Liste;
    int value;
    Maillon * precedant;
    Maillon * suivant;
};

void Liste::InsertionEnTete(int x)
{
  // je corrige ton algorithme  */
  Maillon * temp = new Maillon;
  temp->suivant = tete;
  temp->valeur = x;
  if(queue == nullptr)
    queue = temp;
    
}
void Liste::InsertionEnQueue(int x){
  Maillon * temp = new Maillon;
  temp->valeur = x;
  if(tete== nullptr)
    tete = temp;
  if(queue != nullptr)
    queue->suivant = temp;
  queue = temp;
  
}

@rouloude : pour l'exemple de la voiture vu comme ça cela semble logique .

@koala01 : Merci beaucoup pour ta réponse c'est d'une grande aide . Si cela ne te dérange pas tu pourrais m'expliquer ce que tu as codés de la ligne 3 à 8 de la classe Maillon ? C'est une surcharge d'opérateur ? Quelle en est la fonction ici ?

Aussi voilà mon main : 

int main() {
  Liste liste;
  liste.InsertionEnTete(5);
  liste.InsertionEnQueue(6);
  liste.InsertionEnQueue(50);
  liste.AfficherListe();
}

Et ma fonction afficher : 

void Liste::AfficherListe()
{
  Maillon * curr=new Maillon;
  curr=tete;
  while(curr->suivant!=NULL)
  {
    cout<<curr->value<<"------> ";
    curr=curr->suivant;
  }
}

Quand je souhaite afficher ma liste cela m'affiche seulement le chiffre 6 je ne comprend pas mon erreur.

-
Edité par Anonyme 26 août 2019 à 20:06:41

Pourquoi créer un nouveau Maillon pour afficher ta liste existante et ensuite affecter une autre adresse au pointeur ? (c'est une fuite mémoire).

J'ai aussi fait une ébauche pour te mettre sur les rails (liste simplement chaînée) .

#include <iostream>

class maillon
{
    friend class Liste;
    int val;
    maillon *succ;

    public:
    maillon(int valeur);
};

maillon::maillon(int valeur)
{
    val=valeur;
    succ=nullptr;
}


class Liste
{
    maillon *tete;
    maillon *fin;

public:
    Liste();
    void insertFin(int x);
    void affiche();
};

Liste::Liste()
{
    tete=nullptr;
    fin=nullptr;
}

void Liste::affiche()
{
    maillon *courant = tete;
    while(courant!=nullptr)
    {
        std::cout << "valeur : " << courant->val << "\n";
        courant=courant->succ;
    }
}

void Liste::insertFin(int x)
{
    maillon *nouvMaillon = new maillon(x);

    if(tete==nullptr)
    {
        tete = nouvMaillon;
        fin = nouvMaillon;
    }
    else
    {
        fin->succ = nouvMaillon;
        fin = nouvMaillon;
    }
}

int main()
{
    Liste liste;

    liste.insertFin(1);
    liste.insertFin(2);
    liste.insertFin(3);

    liste.affiche();
}

Mominateur a écrit:

@rouloude : pour l'exemple de la voiture vu comme ça cela semble logique .

@koala01 : Merci beaucoup pour ta réponse c'est d'une grande aide . Si cela ne te dérange pas tu pourrais m'expliquer ce que tu as codés de la ligne 3 à 8 de la classe Maillon ? C'est une surcharge d'opérateur ? Quelle en est la fonction ici ?

C'est, effectivement, une surcharge d'opérateur

Parce que, typiquement, une classe, c'est censé être un fournisseur de services.  Or, ta classe maillon ne fournissait aucun service telle que tu la présentais

Ces opérateurs ne vont en réalité pas servir à grand chose, mais il feront quand même bien joli : au lieu d'avoir un code proche de

void Liste::afficher(std::ostream & ofs){
   /* comme l'a si bien fait remarquer rouloude, tu ne dois pas
    * recourir à l'allocation dynamique de la mémoire pour
    * avoir  un curseur destiné à parcourir la liste
    */
    Maillon * current = tete;
    while(current){
        ofs<<current->valeur<<" ";
        current=current->suivant;
    }
    ofs<<"\n";
}

tu pourras avoir un code proche de

void Liste::afficher(std::ostream & ofs){
   /* comme l'a si bien fait remarquer rouloude, tu ne dois pas
    * recourir à l'allocation dynamique de la mémoire pour
    * avoir  un curseur destiné à parcourir la liste
    */
    Maillon * current = tete;
    while(current){
        ofs<<current->valeur<<" ";
        current=current++;
    }
    ofs<<"\n";
}

En l'état actuel, cela ne changera pas grand chose, parce que l'idéal aurait été de pouvoir modifier le maillon, en lui donnant une forme proche de la notion d'itérateur... (Si tu veux, on peut regarder comment s'y prendre ) Mais bon, on s'en rapproche "un peu plus" de cette manière

Et, bien sur, l'opérateur -- permettra de faire une fonction proche

void Liste::afficheInverse(std::ostream & ofs){
     Maillon * current = queue;
     while(current){
         ofs<<current->value<<" ";
         current = --current;
     }
     ofs<<"\n";
}

int main() {
  Liste liste;
  liste.InsertionEnTete(5);
  liste.InsertionEnQueue(6);
  liste.InsertionEnQueue(50);
  liste.AfficherListe();
}

int main() {
  Liste liste;
  liste.InsertionEnTete(5);
  liste.InsertionEnTete(6);
  liste.InsertionEnQueue(50);
  liste.AfficherListe();
}

void Liste::InsertionEnTete(int x)
{
  // je corrige ton algorithme  */
  Maillon * temp = new Maillon;
  temp->suivant = tete;
  temp->value = x;
  if(queue==NULL) temp=queue;
}

J'imagine qu'il s'agit d'une liste simplement chainée, avec un peu d'overhead pour pouvoir rapidement insérer en fin. Ta fonction membre InsertionEnTete est bizarre. Ça marche pas mieux avec ça?

void Liste::InsertionEnTete(int x)
{
  Maillon *temp = new Maillon;
  temp->suivant = tete;
  temp->value = x;

  tete = maillon;
  if (queue == nullptr) queue = maillon;
}

-
Edité par SpaceIn 27 août 2019 à 15:22:47