Surcharge de template vers des pointeurs

Hello à tous,

Alors je m'amuse un programme un ch'tit truc histoire d'apprendre le C++ et à force de complexifier mon programme j'en suis arrivé à un point ou j'aimerais surcharge "cout <<" vers un vector... Ni une ni deux je me lance dans les templates, grâce à ce site et à d'autres (notamment un pour les 0) :lol:

Et j'en arrive à ceci :
Code:

1 2 3 4 5 6 7 template <typename A> ostream & operator<<(ostream & o,const vector<A> & truc){ out << " (" << flush; for(size_t chose=0;chose<truc.size()-1;++chose) o << truc[chose] << ", " << flush; o << truc[truc.size()] << " ) " << flush; return o; }
Et j'en suis très fier car ça fonctionne très bien... :mouarf:

Mais maintenant je continue mon chemin de petit bonhomme et j'arrive dans cette situation je surcharge une autre classe de la sorte :
Code:

1 2 3 4 5 6 7 8 9 ostream& operator<<(ostream& o, Collection const& c){ o << "La collection contient les "<< c.tailles.size() << " tailles suivantes :" << endl; o << c.tailles <<endl; o << "Mais aussi les " << c.pieces.size() << " pièces suivantes : " << endl; o << a.pieces<< endl; return o; }
Avec dans ce cas :
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 29 #include "./Collect/piece.h" #include "./Collect/taille.h" #include <vector> #include <set> class Collection : public Existante { //Méthodes (publiques): friend ostream& operator<<(ostream&, Collection const&); virtual void existe(); // pas abstraite donc je prototype Existante::existe() ici, afin de la définir dans mon .cc ... Dois-je vraiment le faire ? void addPiece(piece&) ; // pour ajouter une pièce à ma collection hétérogène void addTaille(taille&) ; // de même pour une taille void delallP(); //methode supprimant toutes les pièces de mon vector de piece void delallT(); // idem pour les taille dans tailles protected: vector<taille*> tailles; vector<piece*> pieces; set<piece*> ListP; // j'envisage d'éventuellement utilisé set à la place de vector, vu que j'ai affaire à des pointeurs... set<taille*> ListT; //idem void chaine() const; //Il faut savoir que chaque piece contient un pointeur vers la prochaine pièce... cette methode est censée faire pointer ces pointeurs vers la prochaine pièce dans mon vector de piece... };
Et là, j'ai beau avoir surcharger dans mes classes piece et taille le cout vers des pointeurs de la sorte :

Code:

friend ostream& operator<<(ostream&, piece* const&);
Code:

1 2 3 4 5 6 7 ostream& operator<<(ostream& out, piece* const& d){ out << "Pièce en question : "<< endl; out << tab << "année : " << d->an << endl; out << tab << "créateur : " << d->cr << endl; out << tab << "interet : " << d->in << endl; return out; }
Bin vous vous en doutez, j'ai droit à un joli "Segmentation fault" suivant ce que j'essaye, mais rarement encore, ou alors plus généralement :

Citation:

La collection contient les 3 tailles suivantes :
( 0xbfcf8200, 0xbfcf826c, 0 )
Mais aussi les 2 pièces suivantes :
( 0xbfcf80bc, 0 )

Alors pour info, je ne comprends pas la présence du 0 à la fin... j'ai en réalité 3 tailles et 2 pièces... Mais visiblement il ne les liste pas tous...

Et là, bah j'aimerais bien réussir à surpasser cela sans devoir modifier ma surcharge de vector de la sorte :
Code:

1 2 3 4 5 6 7 template <typename A> ostream & operator<<(ostream & o,const vector<A> & truc){ out << " (" << flush; for(size_t chose=0;chose<truc.size()-1;++chose) o << (*truc[chose]) << ", " << flush; o << (*truc[truc.size()]) << " ) " << flush; return o; }
Car à ce moment ça fonctionne, certes, mais bon après c'est partout ailleurs lorsque j'utilise par exemple des "vector<int>" que ça fonctionne plus...

Alors ??
Ce serait vraiment cool si vous aviez une réponse rapide ;)

J'ai aussi des soucis avec ma fonction "void chaine() const"... elle est censée me connecter toutes mes pièces entre elle...
Bah elle aime pas iterator :
Code:

1 2 3 4 5 6 7 void Collection::chaine() const{ // ATTENTION, algorythme non optimal, à optimiser ;) for(vector<piece*>::iterator i = pieces.begin(); i != piece.end; ++i) { int j(0); do{j++; } while ((*i)->isnext(pieces[j])); // la fonction isnext est une fonction que les piece ont, qui retourne un bool... et qui set le pointeur vers la suivante de la piece en question vers la piece suivante. }
Mais ça c'est un détail : avec un int i, sans utiliser d'itérateur, ça joue donc à la limite ;)
(Mais seulement pour vector<piece*> pas pour set<piece*>, c'est pour ça que j'aurais voulu utiliser un itérateur, plus simple de switcher entre vector et set... si je me décide pour l'un ou l'autre...)

EDIT : j'ai un autre gros bug :
Mes pièces sont en réalité fractionnée en sous-classe...
Et mnt j'ai droit à un segmentation fault à chaque fois suite à la modification de mon code de test : j'ai fait un cout directement vers une pièce sans passer par le vector<piece*>, juste pour voir et avec ce cout il bug complétement... Alors que j'ai bien surcharger mon cout << pour la pièce en question... des idées ? je n'ai rien touché au niveau des pointeurs...

voici mon code de test :
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 29 30 31 32 33 Collection test; test.delallT(); test.delallP(); Untruc f_d(0,8,5); Untruc e_d(2,0,0); Untruc s_d(0,10,0); Untruc e_s(-11,-41,0); Untruc q_s(-18,-21,0); Courbe d(f_d, e_d, s_d, 0.2, 3); // piece courbe... Droite r(s_d, s_d, 0.1); // piece droite... aimant q(e_s, q_s, 1, 12); // pièce aimantée Untruc p1(84, -37, 0); Untruc v1(-20, -28,0); Untruc p2(90, -17, 0 ); Untruc v2(200, -254,0); Untruc f(0,0,0); taille t1(p1,v1,272, 653, 2, f); taille t2(p2,v2,0.938272, 765, 2, f); test.addPiece(d); test.addPiece(r); test.addPiece(q); test.addTaille (part1); test.addTaille (part2); cout << test << endl; cout << d << r << q << endl; // Et c'est depuis que j'ai ajouté cette ligne que j'ai le segmentation fault à chaque fois...

Bonjour,

J’ai pas lus tout ton code mais dans le premier, ligne 5, tu as une erreur qui doit provoquer des segfault :

Code:

o << truc[truc.size()] << " ) " << flush;

À remplacer par :

Code:

o << truc[truc.size()-1] << " ) " << flush;

Ceci provoquera cependant une erreur en cas de vecteur vide (à voir si tu dois gérer ce cas.

Ok merci, je vais voir si ça améliore tout ça ^^

Mais a priori y a pas que ça... :cry:

Bon, bin finalement j'avais déjà solutionné ce problème de la sorte : voici ma surcharge depuis 1 jour :

Code:

1
2
3
4
5
template <typename T>
ostream & operator<<(ostream & out,const vector<T> & A){
    for(size_t j=0;j<(A.size());++j) o << (A[j]) << endl;
    return out;
}

Donc c'est pas ça...
En plus j'ai découvert que le segmentation fault provenait d'une fonction d'une de mes pièces :
ce sont mes pièces courbes !
Je calcule le centre de courbure dans ma surcharge de la sorte :

Code:

1
2
3
4
5
6
7
8
9
10
11
     ostream& operator<<(ostream& o, Courbe const& c){
 
            o << "Dipole : "<< endl;
            o << tab << "poids : " << c.p << endl;
            o << tab << "longueur : " << c.l << endl;
            o << tab << "courbure : " << c.co << endl;
            o << tab << "centre de courbure : " << c.cco() << endl; // ICI ! Si je mets ça en commentaire, plus de segfault...
            o << tab << "pirx :  " << c.pr<< endl;
 
            return o;
            }

Alors ni une ni deux, je vais voir ma fonction cco() dans courbe... elle me parait bien : je ne vois même pas de pointeur dedans !!!

Code:

1
2
3
4
5
6
7
 Position3D  Courbe::cco() const {
            Position3D  dd,d,Cc;
            delta=rs-re;
            delta_unit=~dd;
            Cc=((re+rs)/2.0)+(1.0/k)*sqrt(1.0-pow(k,2)*pow(delta.norm(),2)/4.0)*(delta_unit^Nampreso::e_z);         //Namperso est un namespace personnel, e_z est une position3D qui représente l'axe vertical.... Alors re représente l'extrémité de départ, rs l'extrémité de fin, k la courbure... le tout en vecteur à trois dimension de classe Position3D... je n'ai aucun pointeur !!! 
            return Cc;
            }

Help me ?

Peut-être une division par zéro? Quel compilateur utilises-tu?
Quel est le message d'erreur?

Alors en fait j'ai trouvé en utilisant un débogueur, c'était un problème d'appel récursif dans la surcharge d'un opérateur...