Peut-on stocker un objet quelconque dans vector

Salut à tous!

Voila le code qui me pose probleme, j'ai une erreur de compilation ici pour la deuxieme instruction.
Je pense qu'il y a surement un moyen de mettre mon objet dans mon vector Sequence...
Merci de répondre...

P.S.:Si on ne peut pas le faire ce dont je doute, y a t il un autre type de conteneur qui pourrais me rendre ce service??

Code:

---

1 2 3

Packet* Paquet = new Packet(bufferIn); Sequence.push_back(Paquet);

---

C'est quoi l'erreur.............................

voila l erreur c 'est ca...

error

Code:

---

1 2 3 4 5 6 7 8

error C2664: 'std::vector<_Ty>::push_back' : cannot convert parameter 1 from 'MpegPacket *' to 'const char &' with [ _Ty=char ] Reason: cannot convert from 'MpegPacket *' to 'const char' There is no context in which this conversion is possible

---

Donc tu veux placer un MpegPacket* dans un vector<char> ; normal que le compilo n'y comprenne rien.

Tu essayes de faire quoi au juste ?

Ah oui juste j'avais mis un vector<char> pour faire des tests en fait il me faut un vector<MpegPacket>....

Purée Merci mille fois c'est le genre d'erreur qu'il faut des heures pour trouver...
C'est ridicule j'ai honte... hihihi!

En fait je lis le contenu d'un fichier dans le but de modifier certains paramètres. Je construit donc une la sequence entière des paquets puis je mets chaaque paquets dans une case de mon vector, pour acceder, inserer d'autres paquets etc...
voila j'ai fait la correction et maintenant ca joue.
Merci encore de ta vivacité!!!

Code:

---

1 2 3 4

MpegPacket* Paquet = new MpegPacket(bufferIn); SequenceTS.push_back(*Paquet);

---

Citation:

---

Purée Merci mille fois c'est le genre d'erreur qu'il faut des heures pour trouver...

---

C'est plutôt évident rien qu'en lisant le message d'erreur... :koi:

Code:

---

1 2	MpegPacket* Paquet = new MpegPacket(bufferIn); SequenceTS.push_back(*Paquet);

---

Pas bon. Soit tes MpegPaquet sont copiables et dans ce cas l'allocation dynamique ne sert à rien d'autre que créer des fuites ; soit ils ne sont pas copiables et il faudra stocker des pointeurs (intelligents) dans ton tableau.

mais attend comment ca des pointeurs intelligents??? ce serait l'ideal si je pouvais stocker les pointeurs, mais comment je peux faire ca???
a oui un vector de pointeur sur des MpegPacket
du style:

Code:

---

1 2 3 4 5

vector<MpegPacket*>   MpegPacket* Paquet = new MpegPacket(bufferIn); SequenceTS.push_back(Paquet);

---

Ca c'est mieux deja...non??

C'est pas forcément mieux. Comme je te l'ai dit il faut déjà se demander comment doivent être stockées les instances de ta classe ; si elles peuvent être stockées par copie alors les pointeurs seront inutiles.

Pour les pointeurs intelligents, il y a une explication dans la FAQ et un tutoriel de Miles sur les pointeurs intelligents de boost.

Je ne peux qu'approuver les sages paroles de mon parrain :aie:

Ok vais aller mater ce tuto sur boost. Mais attendez les gars la dans le code que j'ai en dernier, je stocke des pointeurs non?
Et comment je peux savoir si mon objet peut etre stocker par copie, de plus juste tu m'as dit que sotcker les objets pourrait provoquer des fuites memoires... C'est pour ça que je me suis dit que les pointeurs étaient une meilleures solutions sans compter j'aurai certainement un gain de performance si je stocke des pointeures plutot que des objets.

Ma question etait donc:

Code:

---

1 2 3 4 5 6

vector<MpegPacket*>   MpegPacket* Paquet = new MpegPacket(bufferIn); SequenceTS.push_back(Paquet);

---

Ici ne suis je pas en train de stocker des pointeurs???:roll:

Code:

---

vector<MpegPacket*>

---

=> tu as un vecteur de pointeur sur des objets MpegPacket*

donc, pour libérer la memoire, une fois ceux ci inutils il te faudrat faire des
delete MpegPacket*

si je ne me trompe pas :)

Tu auras des fuites mémoires si tu ne fais pas de delete à chaque new ou si tu n'utilises pas de pointeur intelligent pour le faire.
Quand tu faisais :

Code:

---

machin.push_back(*alloue);

---

Tu fais en fait une copie de ton objet, tu ne stockes pas l'objet lui-même, ce qui fais que si tu ne fais pas de delete -> fuite mémoire.
De même si tu fais comme actuellement, si tu oublies d'effacer la mémoire allouée à la destruction ou à la modification du vector, tu auras des fuites mémoires, d'où l'interêt des PI pour t'éviter de penser au delete.

Citation:

---

Et comment je peux savoir si mon objet peut etre stocker par copie

---

En général lorsque l'on conçoit une classe c'est la première chose qu'il faut se demander. Ca dépend de ce que fais ta classe, et de la manière dont elle le fait. En gros, demande toi si le fait d'écrire A = B (avec A et B des instances de ta classe) te poserait des problèmes.

Donc si je resume soit j'utilise les PI soit je suis condamne a faire des delete[] au bon endroit! Et dans mon cas faire des delete ca va etre complique puisque j'aurai une quantité très importante d'objet (probablement plusieurs centaines vois pluisieurs milliers).

Enfin quoique en fait c'est pas si complique que ca il me suffirait de faire une boucle à la fin de mon programme qui detruirait iteravtivement chacun des objets, ca marcherais ca non ?

Oui, ça marcherait, mais comme tu as tout sous la main ;) C'est plus simple :)

Ouai ok vais sérieusement regarder alors en tout cas merci a tous.
:mouarf:
On va certainement se croiser quelque fois puisque je serai sur ce forum certainement de plus en plus souvent. Etant donné la qualités de ces membres.

Merci encore et à bientôt:P

Hum vu que vous parlez des vector et des fuites de mémoire, j'ai un gros doute (je sais jamais si je supprime bien le tout), est-ce que il y a fuite de mémoire ici :

Donc en gros j'ai un tableau de quatre pointeurs sur des objets Sprite :
Sprite * g_pPouletSprite [4];

Puis j'utilise des new pour les quatres :
g_pPouletSprite [0] = new Sprite (g_pPouletBitmap, rcBounds, REBONDIR);
ainsi que pour tous les autres, et je les stocke tous dans mon vector suivant un ordre Z.

Puis à la fin du programme je fais un delete sur le bitmap qui est associé au Sprite, et j'appelle ma fonction SupprimerSprites qui fait ceci :

m_vSprites.erase (m_vSprites.begin(), m_vSprites.end());

Ya t'il une fuite de mémoire ?

Merci ^^

Oui, il n'y a aucun delete qui correspond à tes new. La règle est simple, il n'y a pas à chercher midi à quatorze heures.

De plus ton erase n'est rien d'autre qu'un clear(), et est inutile si tu n'utilises plus ton tableau après.

Ok donc le erase sert à rien ?

donc il faudrait que je fasse...

vector <Sprite *>::iterator s1;

for (s1 = m_vSprites.begin() ; s1 != m_vSprites.end() ; ++s1
{
delete (*s1);
m_vSprites.erase (s1);
}

C'est mieux ou yen a toujours ?

Non, sors le erase de la boucle et fais un clear, ça ira mieux. Comme dit, avec des pointeurs intelligents, tu pourrais faire comme tu le faisais avant :D

vector <Sprite *>::iterator s1;

for (s1 = m_vSprites.begin() ; s1 != m_vSprites.end() ; ++s1
{
delete (*s1);
}

m_vSprites.clear();

C'est mieux ? ^^

Hum je vais essayer de voir ton tutoriaux sur les pointeurs intelligents, c'est vrai que si j'ai plus à m'occuper à faire les delete de tous mes pointeurs (c'est bien ça l'intêret ?), ce sera super ^^.

EDIT : ah oui, pendant que j'y suis... Sur mon livre de C++ (enfin dans mes souvenirs ^^), ils disent que l'itérateur est un pointeur.

Donc que dans l'exemple plus haut s1 est un pointeur vers un élément de la liste. Mais alors pourquoi j'ai à fait lors d'appels de fonctions par exemple de d'abord déréferencer le pointeur et après en plus faire le -> (*s1)->Fonction(). le s1->Fonction() ne fonctionne pas...

Ce sont des pointeurs de pointeurs ?

EDIT 2 : oh que je suis con, ça doit être des pointeurs de pointeurs en effet vu que c'est un vector de pointeur ^^.

Citation:

---

C'est mieux ? ^^

---

Oui.

Citation:

---

oh que je suis con, ça doit être des pointeurs de pointeurs en effet vu que c'est un vector de pointeur ^^

---

Oui.
Par contre attention : les itérateurs se comportent comme des pointeurs, mais n'en sont pas forcément. Dans le cas de std::vector<>::iterator c'est parfois le cas, mais ce n'est pas garanti. Enfin de toute façon ce n'est qu'un détail d'implémentation.

Pour faire simple le fonctionnement des pointeur intelligent est le suivant :

(la STL en possede : auto_ptr)

Code:

---

1 2	PointeurIntelligent <Objet> Pio = new Objet (parametres) ;

---

a partir de la le delete sera automatique
avec des containers, par exemple un vector de sprites:

Code:

---

1 2 3 4 5 6

vector < PointeurIntelligent<Sprite> > vSprite ;   vSprite.push_back ( new Sprite (parametres)) ; vSprite.push_back ( new Sprite (parametres)) ; vSprite.push_back ( new Sprite (parametres)) ;

---

et c'est tout, lorsque tout sera inutile, ils seront delete automatiquement.

Dans les Pointeurs Intelligents les plus connus sont :
- loki
- Boost (un tuto est dispo sur le site)

Les auto_ptr ne sont pas compatibles avec les conteneurs, attention ;)

Ah oui, d'après ce dont je me souviens, la lecture retirerait l'objet du conteneur (à supposer que ça compile sans violer la const-correctness...)

Les shared_ptr de boost (avec comptage de références, c'est ça?) marchent, par contre, non ?

Oui, les pointeurs de Boost implémentent un compteur de référence ou empêche la copie, donc pas de souci.
Le pb des auto_ptr, c'est que la copie transfert la responsabilité, et lors des copies pour comparer et compagnie, on perd l'objet.

en effet a noter aussi qu'il n'aime pas le passage par copie sur une fonction pour le meme probleme de transmission de responsabilite.

Donc, en fait, auto_ptr, ça veut juste dire "je fais automatiquement un delete dans le destructeur"...
Je pense que l'auto_ptr ne devrait pas être copiable, avec tous ces inconvénients...

Les std::auto_ptr<> sont parfaits pour ce pour quoi ils sont faits: implémenter une sémantique de déplacement et assumer des responsabilités passagères.

Il n'est pas rare que mes fonctions reçoivent des auto_ptr<> quand elles sont des puits pour les données pointées reçues -- je préfère ça à une fonction qui prend un pointeur et qui signale dans un endroit obscur de la doc que la donnée pointée sera détruite. Dans le même genre, j'avais croisé un article qui présentait des pointeurs intelligents nondeletable<>. J'aime bien l'expréssivité rajoutée, même si tout devient plus verbeux.

Et il n'est pas rare non plus que je renvoie des auto_ptr<> pour mes fonctions qui agissent comme des sources de données. L'appellant sait immédiatement qu'il devra assumer la responsabilité de la donnée récupérée.

NB: Dans les cas sans déplacement, il y a les boost::scoped_ptr<> au détail qu'ils ne disposent pas de fonction release au contraire des auto_ptr<>. Du coup, il m'arrive d'écrire:

Code:

---

1 2 3 4

std::auto_ptr<T> t( new T(42) ); truc_qui_peut_lever_une_exception(); mon_vecteur.push_back(t.get()); t.release();

---

Oui, il existe autant de SmartPointer que de cas de figure.

C'est a toi de voir ce qui te conviens le mieux.
Personnellement je deteste multiplier les possibilité, je prefere largement n'avoir qu'un SmartPointer et m'arranger pour qu'il marche a chaque fois sauf cas extreme.

Da cette optique j'ai fait ma propre classe de PointeurIntelligent, mais comme certain cas sont impossible.

* les tableaux [], donc on prend des vector (dans un sens c'est pas plus mal)
* les cycles (et la c'est trop gourmand a implementer)

A noter que c'est un excellent exercice.

C'est un excellent exercice, mais 99% des résultats de ces exercices ne seront pas à utiliser, les plus grands se sont plantés sur cet exercice périlleux !
Enfin, pour stocker des pointeurs dans un vector, le plus simple est de les encapsuler dans des shared_ptr<>