Reprise du message précédent :
et si tu réfléchissais un peu avant ? si on te dis de séparer liste et facture, c'est parce que ça n'a rien à voir et que ça t'aide à appréhender le problème de collection de manière plus simple.
 
fait ton UML/ADT de Liste, code là, après tu bourre tes factures dedans et ça marche

"faire un facturier (100 factures ) par classe auto référencielle"
ouinnnn

mais forcément que liste est séparée de facture
 
puisque je veux que facture se référence lui meme pour 100 factures..
 
et c quoi un ADT??
 
j'ai déja fait l'uml et puis je bourre mes factures
justement je sais pas cmt et cmt les relier

tout a fait    

t'as fait l'UML d'une liste ? (si y a 1 seule fois le mot facture dedans, repars pleurer)

 
Comme je l'ai dit, ton prof ne veut pas d'une classe collection.
Tu as 2 méthodes à coder en particulier :
 
AjoutFacture(Facture* f) qui attache la facture f  
Facture* Suivant() qui rend l'objet suivant dans la liste
 
A partire de là, à toi de voir comment tu gères l'effacement et la gestion de la mémoire.

on doit pas lire le français pareil. Pour moi un facturier, c'est une collection de facture. Après son prof lui demande de faire un facturier de 100 éléments pour tester.

 
J'ai pas de leçon de français à recevoir d'un mec qui arrive dans un topic et qui confond "TA GUEULE" et "BONJOUR"  
 
En plus l'expression "classe auto référencielle" me parait suffisamment clair à ce niveau.

ok supposons que je fasse une boucle tant que.
 
tant que le gars veut encoder une facture
         je crée une facture du nom Une Facture
          j'appelle la fonction qui lie la facture a la  précédente
 
fin tant que
 
 
ca parait  simple mais faut le faire
     

///////////////////////////////////////////////////////////////
//    PROGRAMME QUI ENCODE DES FACTURES DANS UN FACTURIER    //
//    auteur : *******                            //
///////////////////////////////////////////////////////////////
#include <iostream>
#include <fstream>
#include <iomanip>
#include "conio.h"
#include "Facture.h"
#include "Client.h"
using namespace std;
 
/////////////////////////////////////////////////////////////////////////////////////
 
int main()
{
 ofstream SortieFichier("c:\\CollectionDeFacture.dat",ios::app);
 
 char reponse='n', reponsefinale='n' , reponsefact='n';
     
 
 
 Client UnClient; //puisqu'on travaille avec les objets et non avec les classes,
                  // il faut bien en créer ! Voici un objet Client .
    Facture UneFacture; // création d'un objet Facture .
 
 
    while ( reponsefinale == 'n' || reponsefinale =='N' )
 {
      while ( reponse == 'n' || reponse == 'N' )
   {
   UnClient.EncodeClient();
   cout << "\nCe client doit-il etre enregistre pour une facture?? (O/N) --->" ;
   reponse=getche();
         cout << endl;
 
   if ( reponse == 'n' || reponse == 'N' )
   
    system("CLS" );
   }
   //notre client est maintenant enregistré.
   
 
 
 
   //il nous faut créer sa facture.  
   cout << "\n\nentrez les references de votre nouvelle facture "<<endl;
      cout << "------------------------------------------------"<<endl;  
 
       
      while ( reponsefact == 'n' || reponsefact == 'N' )
   {
        cin >> UneFacture;    //l'opérateur >> a été surchargé dans Facture.h
     cout << "\nCette facture doit-elle etre ajoutee au facturier?? (O/N) --->";
     reponsefact=getche();
        cout  << endl;
   }
      // sa facture est maintenant enregistrée.
      //et on va l'enregistrer dans le fichier    c:\\CollectionDeFacture.dat  
      SortieFichier << UneFacture << endl;
       
       
      //mais il nous faut encore ajouter cette facture au facturier  ListeDe.
    //UneFacture.pFactureSuivante = new Facture ();
// c'est ici que c'est chaud[#ff0e00]
 
 
 
 
    cout << "\n\non stoppe l encodage et le programme ici ?? (O/N) --->" ;
    reponsefinale=getche();
 cout << endl;
 
    if ( reponsefinale == 'N' || reponsefinale =='n' )
    {
      reponse='n';
   reponsefact='n';
      system("CLS" );
    }
 
    }
 
 
 
 
 return EXIT_SUCCESS;
}

 
Il s'adapte au niveau du sujet : titre en majuscule, synonyme de cri dans les échanges écrits sur internet.
(titre qui, au passage, n'a toujours pas changé)

je sais pas cmt on change le titre je viens jamais

antp > tu gueules pas sur le non emploi des balises [cpp] ?

 
"" dans le premier post
 

 
Une chose à la fois

edit ton premier post

voila j'ai modifié le titre du post

plus qu'une demi heure pour chainer ces objets ..

AjoutFacture(Facture* f) qui attache la facture f  
Facture* Suivant() qui rend l'objet suivant dans la liste  
 
 
en détail ca donne?
car je vois pas la nuance entre les deux fonctions

AjouteFacture(Facture* f) fait un pFactureSuivante = f;
Suivant() retourne pFactureSuivante
 
Petit conseil : Pense à initialiser pFactureSuivante à NULL dans le constructeur et n'oublie de coder le destructeur correctemement.

voila est ce qu'elles sont reliées la?
 
 
cin >> UneFacture;    //l'opérateur >> a été surchargé dans Facture.h
   
   
      // sa facture est maintenant enregistrée.
      //et on va l'enregistrer dans le fichier    c:\\CollectionDeFacture.dat  
      SortieFichier << UneFacture << endl;
       
       
      //mais il nous faut encore ajouter cette facture au facturier  ListeDe.
    UneFacture.pFactureSuivante = new Facture();

 
C'est pas possible ce que tu ecris (et c'est mal) :  pFactureSuivante est private, d'où l'interet de l'accesseur. Tu as bien dû apprendre ça dans tes cours ?

je l'ai mis en public pour pas me faire chier

donc?

Ah bah forcément, c'est sûr que c'est pas gagné... Au moins j'aurais eu le mérite d'essayer. Comme on dit : "Good Luck"

il est maintenant trop tard...
j'ai un éxécutable ki tourne.....  
si on l'éxécute et si on ne regarde pas dans le code  
on aura l'impression que le travail est terminé grâce aux boucles while imbriquées....
 
bon bein je croise les doigts... mais je prend pas le prof pour un idiot....
 
je vous laisse , vous remercie , et vais a ma mort..

évidemment si tu lui parles de code, alors qu'il n'arrive pas à concevoir clairement son application ... tu l'as dévoyé, maintenant t'assumes

je suis en classe et j'ai rendu l'exercice
 
je vais quérir la clémence et l'indulgence lol
 
ah lala

 
J'avais un prof avec qui ça marchait.
Pour avoir les points une belle interface graphique était mieux qu'un beau code.
Genre l'écriture d'une classe "BigInteger" en C++, pour traiter des nombres composés d'un nombre 'illimité' de chiffres : je m'étais arrangé pour bien optimiser le truc, mes multiplications n'étaient pas qu'une suite d'additions contrairement à d'autres. Donc mon code était bien plus rapide. Puis le jour du test, alors que moi je testais avec des nombres de centaines de chiffres le prof testait avec des nombres qui auraient pu tenir dans un int

on peut avoir une image d'un schema statique de classes avec facture dedans?
 
juste pour vérifier que le schéma lui même est faux comme je le pense

bein c'est une classe facture qui est reliée a elle meme.
vous savez en forme de récursion

 
encore pire que ce que je pensais

 
Bah là, on a un prof qui demande de pourrir une classe Facture avec une auto-référence (parce que STL, ça fait pas partie du langage, donc on l'apprend à la fin), plutôt que d'apprendre ce que sont les patterns, qu'est-ce que le Composite Pattern, est-ce qu'il a sa place ici plutôt qu'une bête collection, etc.
 
Mais oui, j'ai souvent eu le même problème: les profs aiment bien noter sur des critères simples. Donc si tu fais un programme complexe, ton code devient forcément plus complexe, donc moins "pur", donc moins bien noté.  
 
Sans compter les intégristes qui ne supportent pas de voir de code dans la fonction main() (c'est comme ça qu'on devait apprendre il y a 20 ans), ceux qui ne supportent pas le code où il y a moins de 40% de commentaires, et ceux qui ne supportent pas qu'on ne passe pas 150 paramètres dans toutes les fonctions, pour éviter les variables globales...

en general c'est quoi les profs de prog ? ce sont surement pas des professionnels ??

50 à 60% ont "appris" l'informatique sur le tas et enseignent à faire du code bien crade
40 à 30% sont pas trop mauvais mais tellement mauvais pédagogue qu'en sortie c'est pire que leurs potes d'au dessus
10% sont à la fois bons et pédagogues, mais ils demandent des crédits et font faire des trucs intéressants aux élèves ( ) donc ils se font virer très vite  
 
 
En résummé, 90% des profs d'informatique sont profs parce qu'ils sont incapables de programmer (il est bien connu que ce qu'on enseigne le mieu est ce qu'on ne connait pas)

ok je vois

 
Il y a un paquet de profs dans le secondaire qui sont profs parce qu'ils sont trop mauvais pour faire autre chose. My new pet hate, c'est les profs d'anglais, qui sont souvent d'une nullité hors du commun en collège et lycée. Et ça j'ai compris pourquoi en rencontrant des "futurs" profs d'anglais à Londres. Ptain, quels boulets...
 
 
Bon, pour recentrer un peu. Le problème, c'est que beaucoup de profs d'algo n'ont jamais programmé dans l'industrie, avec des contraintes débiles, des collègues lourds, des problèmes utilisateurs, etc. Bref, ils pensent dans l'absolu, et insistent sur plein de trucs qui sont religieux (décomposition des fichiers, des fonctions, commentaires, variables globales, etc). Et aucun ne s'attardera sur des trucs bénêts mais indispensables (unit-tests, source-code control, profiling, etc.).
 
En modélisation objet, c'est pire, parce que tu te tapes systématiquement des trucs àlacon (Distributeur de billets, machine à café, feu-rouge), et qu'on te force à les modéliser à la con (sans jamais te parler de Design Patterns, etc.).
 
Bref, c'est très abstrait et théorique tout ça. Moi je m'étais tapé 2 points en moins en algo une fois, parce qu'au lieu de resortir l'algo de la prof en contrôle, je l'avais optimisé au niveau des divisions par 2 (un truc de tas je crois), et qu'elle avait eu la flemme de comprendre mes modifs...

Et encore, ya pire, ya les profs d'allemand  

C'est trop vrai  
(j'en ai eu 2 sur 3 quand même )
 
Enfin bon, en plus de ces deux remarques
   
Lam's, ton post est dans le vrai à environ 350%, et franchement je me demande si je vais pas l'imprimer pour le distribuer à la sortie des écoles/facs

ouais c'est ce que je pensais.
 
au stade de la modelisation en UML, avoir une relation d'une classe sur elle même n'est pas forcément mauvais en soi (même si on a de gros doutes dans ton cas).
 
Par contre, en passant à l'implémentation en C++, le fait de le traduire par un pointeur "facture* next", ça c'est clairement mauvais  

 
Non, le prof demande une classe autoréférentielle. C'est encore un exercice stupide et anti pédagogique, parce qu'aucune personne sensée ne modéliserait une facturation de cette manière aujourd'hui.
 
Et bien sûr, la STL sera traitée par dessus la jambe en 2h au mieux si le programme le permet.

ouais ben là alors, si vous vous pissez dessus devant votre prof. Moi j'aime la programmation, parce que c'est un truc de créatif. Je comprends pas comment en milieu universitaire on peut se laisser imposer des inepsies. Et quand je rends un TP, les fioritures sont toujours apprécié. Allez plus loin, c'est montré qu'on a compris.

le prof a dit que ceux qui ont remis le travail auront quand meme des points contrairement a ceux qui n'ont rien rendus.....
 
bon bein en parlant de jambe ca me fait une belle jambe.
 
il  nous a dit clairement qu'il sait que ce qu'il a demandé était dur
hahahahahaha
 
enfin..... est ce pour qu'on comprenne que ca existe et comment ca marche?
 
 un truc inutile selon certains.....