bonjour a tous
alors voila je débute en c++
et voila que mon prof nous donne seulement 2 jours pour faire cet exercice....côté.
 
nous avons réalisés l'uml et en fait ce que je ne sais pas faire
c'est enchainer 100 objets chacun contenant un *ptrSuivant      qui pointe vers l'objet suivant.
 
voila j'aimerais une aide détaillée(voire le code) si possible merci à tous

Tu rémunères combien pour qu'on fasse ton boulot à ta place ?

je demande pas de faire le boulot à ma place !
 
j'ai déja tout préparé dans mon code  
il me manque seulement une aide car je ne sais pas comment représenter une liste chainée en c++.
 
ca demande pas bcp je pense que c'est juste un petit service ca se paye ca?

Comment représenter une liste chaînée ?
Ca dépend, il y a plusieurs méthodes.  
Si on pouvait jeter un oeil sur ton modèle UML, ça aiderait.
Et puis tu devrais poster ton code pour voir à quel niveau tu bloques.

TA GUEULE

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

moi je veux bien mais mon code est composé de 2 fichiers .h et de 3 .cpp
 
et puis le modele uml je fais cmt pour le poster? je le essine dans paint  et je le poste?

tu postes rien. tu te mets au taf

on m'a parlé de classes auto référentielles.
 
j'ai une classe facture qui instancie un objet UneFacture qui possède un *ptrSuivant     qui pointe vers une autre facture du meme type.
 
je ne sais pas trop cmt créer 100 factures sans saturer la mémory.

il est où le topic des bestof parce que là on en tient un bon

et surtout les relier

operateur =

Poste seulement la déclaration de la classe collection, ça permettra d'avoir une idée sur la méthode mise en oeuvre.

Au fait : ignore la pollution de Taz, il ne sait faire que ça.

non, je vois juste un topic hors charte, avec un titre irritant et un gus parano qui a pas envie d'en foutre une ramée.

j'ai fait une classe Facture
 
ma classe Collection est vide
 
class Facture  
{
 
private:
         int id; //  numero d'identification de la facture.
   Date Datef; // objet de type Date crée.
   float  MontantHTVA; // le montant hors tva.
   Facture *pFactureSuivante; // pointeur du type de la classe elle-même.
public:
 
 Facture();
 virtual ~Facture();
 int getid();  
    Date getDate() ;
    double getMontantHTVA();
 void setid();
 void setDate();
 void setMontantHTVA();
      AjoutFacture();
 
inline friend ostream &operator<< ( ostream &sortie, Facture &UneFacture )
{
   sortie << "\n\n--- Votre facture est ---\n\n"  
       <<"\nreference facture: "<<UneFacture.id  
    <<"\ndate facture: "
          << UneFacture.Datef.jour<<"/"<<UneFacture.Datef.mois<<"/"<<UneFacture.Datef.annee
    <<"\nmontant htva: "
       << UneFacture.MontantHTVA << endl ;
   
 
return sortie;
}
 
inline friend istream &operator>> ( istream &entree, Facture &UneFacture )
{
    cout <<"\nreference facture: ";
    entree >> setw(4) >> UneFacture.id; // entre le numero de la facture.
 cout <<"\ndate facture (JJMMAAAA) : ";
 entree >> UneFacture.Datef.jour >> UneFacture.Datef.mois >> UneFacture.Datef.annee;  
 cout <<"\nmontant HTVA facture: ";
 entree >> setw(5) >> UneFacture.MontantHTVA;   //entre le montant HTVA.
 
 return entree; // permet cin >> a > etc
}
 
};

c'est ... flou comme model
 
tu voudrais pas séparer l'implementation de la liste de la facture ?

ouais, parce que sur ton schéma UML, ça doit apparaître clairement qu'une Collection est associé à * Facture ...

Ouip, même si en algo, on le fait souvent (de relier les noeuds entre eux), en C++, on évite :  
 - chaque facture est indépendante, et n'a pas conscience de l'existence des autres factures
 - ta classe Collection gère la liste chaînée de facture.
 
Collection devient alors une simple instanciation de la clase list de la STL avec des pointeurs sur Facture. Et ta classe Facture n'a plus le pointeur vers la Facture suivante.
 
Le lien vers la classe list a déjà été donné par cris56
 
edit: le lien était de cris56, pas de Taz. A mon avis, Taz n'a jamais entendu parler de la STL...

edit : rien  

séparer l'implementation de la liste de la facture ?
bon j'ai mis en rouge ce qui peut permettre un chainage... mais c flou effectivement
 
 
class Facture  
{
 
private:
         int id; //  numero d'identification de la facture.
    Date Datef; // objet de type Date crée.
   float  MontantHTVA; // le montant hors tva.
 Facture *pFactureSuivante; // pointeur du type de la classe elle-même.  
 
public:
  Facture();
 virtual ~Facture();
 int getid();  
    Date getDate() ;
    double getMontantHTVA();
 void setid();
 void setDate();
 void setMontantHTVA();
      AjoutFacture();
};

il est ou le post de Smaragdus ?

Sais-tu quel est le rôle de AjoutFacture() ?
Elle n'a aucun param d'entrée donc comment peut elle faire un lien ?

ajoutFacture()
n'a aucun param  
je sais bien car je ne sais pas bien ce qu'elle doit faire.
 
en tout cas il faut qu'elle ajoute la facture a la collection.
 
mais il faut un début.... et puis un chainage jusqu'a la 100èmè et derniere facture qui elle pointe vers NULL.
 
mais bon c trop dur

Les forumeurs sont priés de ne pas mettre leurs titres en lettres capitales, conformément aux règles en vigueur sur cette section

 
Oui mais non, on t'a dit de ne pas faire comme ça.  
 
Relis mon message, et pose des questions si tu comprends pas, au lieu de t'entêter dans ton système de liste chaînée préhistorique.

c'est pas que je m'entete
c'est le prof qui veut que ce soit une classe autoréférentielle donc je suis obligé de passer par la

 
 
ta pas de chance d'avoir un prof normal

ok si je relis
je comprend que je dois créer une classe liste qui pointera vers 100 objets factures

mais on n'a pas encore vu la STL !!
argh !!
c le dernier  chapitre du cours

 
ok, c'est bien ce qu'il me semblait. Donc tu pas besoin de classe Collection.
Sinon il te faut plusieurs méthodes pour te balader dans la liste chaînée, effacer un item, ajouter un item etc...

le lien proposé est bien gentil mais en anglais et je n'ai plus qu'une heure pr terminer

 
ben prend un peu d'avance

il a demandé aux plus forts d'effacer une facture bref de faire un menu .....
 
mais il veut simplement 100 factures par classe auto référencée

 
Mouais  

mince alors, on a une solution, mais ça gère que 99 factures ... pas de chance

mardi il nous a demandé ca pour jeudi
donc ca fait 2 jours !
et sur la vie de ma mère que j'ai pas arreté de me questionner, d'implémenter et de pas trouver
hier jusqu'a 5 h du mat !
 
enfin on est jeudi et c chaud..... il me reste 1h

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