Pointeur NULL dans conteneur c++

Bonjour,

Je suis actuellement sur un projet et un probleme me taraude.
Mon programme possede une map<std::string, Objet*>.

L'objet (Enfin pointeur sur objet) en question je l'initialise et le test, il marche sans soucis.
Malheureusement lorsque je le rentre dans ma map, le pointeur passe a NULL.

Etant debutant en C++ et ne connaissant que tres peu le debugger de visual c++ (IDE sur lequel je developpe) je me tourne vers vous car de toute evidence il y'a un soucis ^^.

Les sources ne sopnt pas poste car il y'a pas loin de 400 ligne pour ma classe et je ne sais pas quoi vous donner.
Donc n'hesitez pas je reste a disposition ;)

Merci par avance :D

Salut, et bienvenue sur le forum...

Ce que tu pourrais donner, c'est une idée de la hiérarchie de classe basée sur Objet (car, je présumes que si tu veut placer un pointeur dans une map, c'est pour l'utiliser polymorphiquement :P), la définition de ta classe objet (et plus particulièrement les fonctions virtuelles), et le code de la fonction dans laquelle tu essaye de placer cet objet dans la map...

De manière générale, l'idéal est de donner un code minimum compilable qui reproduise le problème, mais il est vrai que, lorsque l'on travaille avec une orientation objet et une otpique polymorphe, cela signifie bien souvent fournir le code de la classe de base, celui d'au moins une classe dérivée et celui de la fonction qui pose problème :P

Ci-joint le fameuse Objet*

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 34 35 36 37 38 39 40

#ifndef _USER_HH_ #define _USER_HH_   #include <cstdlib> #include <iostream> #include <string> #include <map> #include <utility>   #include <boost/bind.hpp> #include <boost/smart_ptr.hpp> #include <boost/asio.hpp> #include <boost/thread.hpp>   typedef boost::shared_ptr<boost::asio::ip::tcp::socket> socket_ptr;   class user { socket_ptr _sock; std::string _log; std::string _pwd; bool _state;   public: user(); user(bool state, socket_ptr sock); user(std::string login, std::string passwd, bool state, socket_ptr sock); ~user();   socket_ptr getSock() const; void setSock(socket_ptr); std::string getLog() const; void setLog(std::string&); std::string getPasswd() const; void setPasswd(std::string&); bool getState() const; void setState(bool const); }; #endif //!_USER_HH_

---

Et ci joint le fameux bout de code qui il me semble pourrait convenir :
Nous sommes dans une methode

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

std::map<std::string, user*> users;   void function2(user *u) { users.insert(std::pair<std::string, user*> (u->getLog(), u)); /* Truc bidon d'exemple mais il ne le match meme pas dans le tableau */ std::cout << "Authentification de " << users[u->getLog()]->getLog() << std::endl;   /* Et si toute fois il le matchait, le pointeur serait vide */ }     void function1() { if (1) { user *u = new user(false, sock); u->setLog() = "Toto"; function2(u); } }

---

Le code n'est peut etre pas aussi complet que ce que tu m'as demande neamoins il represente le bout de code qui pose probleme :)

Cordialement,

Je ne pense pas que ça resoudra ton problème, mais tu devrais utiliser std::make_pair plutot que cette syntaxe.

Au delà de ça, tu peux peut être ajouter une assertion ( != null) au début de ta fonction voir?

Citation:

---

Je ne pense pas que ça resoudra ton problème, mais tu devrais utiliser std::make_pair plutot que cette syntaxe.

---

Je viens d'essayer et e effet le resultat est le meme :(

Citation:

---

Au delà de ça, tu peux peut être ajouter une assertion ( != null) au début de ta fonction voir?

---

Cela ne fera que contourner le probleme en cas de non respect de la condition (Ce qui se passe en ce moment).

Ce que je voulais dire, c'est qu'avec l'assertion, au moins tu sais que le code de ta fonction est correct et que le problème viens de l'extérieur, autrement dit du new user(...).

Sauf bien sur si l'assertion de faillis pas.

Au passage, pourquoi

Code:

---

u->setLog() = "Toto";

---

Compile?

setLog requiert un paramettre et retourne void, ce code ne devrait pas compiler...

Ok je commence a comprendre, si tu as voulu faire

Code:

---

u->getLog() = "Toto";

---

Alors tu pensais peut être assigner la valeur au string contenu dans (*u), mais en réalité tu l'assigne à une copie. Ca rends l'insertion dans la map fausse puisque u->getLog() a toujours la valeur par défaut "".

Pour que ça marche, getLog() doit retourner une référence, pas une copie.
Je serais toi, je mettrais plutot getLog() const qui retournerait une référence constante, obligeant l'utilisateur a utiliser setLog() (et ça crasherait si on essayait de faire autrement).

Non du tout c'est moi dans la precipitation qui me suit tromper

Code:

---

1 2 3 4

u->setLog("Toto");   std::cout << u->getLog() << std::endl;

---

Dans ce cas, "la vérité est ailleurs" ;)

On peut voir le code de setlog et getlog?

A mon avis getlog ne retourne pas ce a quoi on s'attends...certainement parceque setlog ne fait pas exactement ce qu'on pense...

Honnetement j'en doute le getLog me retourne ce que j'attend de lui, la ou ca peche c'est la map d'objet*.
Lorsque je cherche a l'utiliser, la key est bonne mais l'objet se situe en 0x000000.
Soit un pointeur NULL.

getLog et setLog son des geteurs et seteurs tout ce qu'il y'a de plus banale :

Code:

---

1 2 3 4 5 6 7 8 9

std::string user::getLog() const { return (this->_log); }   void user::setLog(std::string& log) { this->_log = log; }

---

C'est le comportement de la map quand la clée ne corresponds à rien dans la map (elle insert un nouvel enrgistrement avec une valeur par défaut pour la valeur liée a la clée, soit NULL pour un pointeur).

Autrement dit soit tu insert bien null (mais tu dis que c'est pas nul a l'insertion?) soit il y a quelque chose d'incorect dans getLog ou setLog, donc sans montrer le code je vois pas comment t'aider.

Ce ne sont pas des accesseurs triviaux? (au passage, tu devrais passer une référence constante dans setLog, mais ça devrait pas changer grand chose au problème.)

edit> Ok alors le problème est encore autre part.

Essaie de mettre un breakpoint sur la ligne d'insertion, et regarde dans les variables du debugger voir le contenu de ta map après l'insertion.

Reponse du debugger :

Code:

---

1 2

+users[1](("Nox",0x00000000 {_sock={...} _log={...} _pwd={...} ...})) std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,user *,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,user *> > >

---

On dirait qu'il ne prend pas en compte le pointeur que je lui met a l'insertion ... Ca m'inirve ^^ Pourtant je le teste avec des getLog() avant et il me renvoi la bonne valeur !

Juste pour voir le comportement, essaie de faire:

users[ u->getLog() ] = u;

a la place de l'insertion?

Tu peux aussi :
1/ Tester la valeur en retour de ton insertion: (std::pair<iterator,bool>, teste si l'itérateur est valide et si bool est vrai (nouvel élément) ou faux (élément déjà existant)
2/ Essaies std::map::find juste après ton insertion. Vérifie si l'itérateur et valide et alors quelle est l'@ de user.

Accessoirement, je ne vois pas l'intérêt de stocker les user par pointeur vu que les membres de user utilisent déjà le RAII pour les données allouées.

Je crois que Klaim a trouve la solution neamoins je ne comprends pas bien pourquoi ):

En revanche je n'ai pas compris l'histoire des RAII, puis je avoir une explication ? :D

Merci par avance :ccool:

ps : Je mange, finis mes test et passe le topic a Resolu un fois les tests finis.

Ce n'est pas normal...
le code que je t'ai proposé crée une pair avec un pointeur null comme valeur et la clée donnée comme clée, puis assigne au pointeur la valeur après le =.

Si ça ça marche, alors l'insertion doit marcher aussi.

Ou alors il y a un problème plus grave dans ton programe : vérifie l'état de ta map avant l'insertion voir si il n'y a pas des trucs louches dedans.

Il se peut qu'un autre bout de programme touche a la map... ou à la mémoire qu'elle manipule. Auquel cas, bonne chance :aie:

Bien entendu j'initialise mon user avant et je le rentre de l maniere que tu m'as dit dans ton dernier post et ca a regle le truc... magiquement :D

Salut,
Quel compilateur as-tu ? Comme Klaim, je ne vois pas pourquoi []= corrigerait le bug de insert :koi:
Concernant le stockage valeur/pointeur :
1/ Ta classe ne contient aucune fonction virtuelle ;
2/ la socket est stockée sous forme de pointeur intelligent ;
3/ les autres membres sont 2 string et un booléen.
Tout ça se copie très bien et je ne pense pas qu'il y ait un coût rédhibitoire.
Donc, pourquoi ne pas avoir une map par valeur : std::map<std::string,user> ? Si tu veux vraiment mettre des pointeurs, pourquoi ne pas avoir mis des pointeurs intelligent ?
De la même façon, si c'est pour mettre des accesseurs aux membres de ta classe, et bien, rends carrément public ces membres. Ca ne sert à rien de les mettre en privé si c'est pour ajouter des getter/setter.

Yop

Citation:

---

Quel compilateur as-tu ? Comme Klaim, je ne vois pas pourquoi []= corrigerait le bug de insert

---

J'uilise celui par default de visual c++ je ne pourrais pas te donner le nom comme ca, que cette methode marche m'egare neamoins je pense simplement que mon u->getLog() doit etre different d'une string entre double quotes.
(A cause des constante ?)

Citation:

---

1/ Ta classe ne contient aucune fonction virtuelle ;
2/ la socket est stockée sous forme de pointeur intelligent ;
3/ les autres membres sont 2 string et un booléen.
Tout ça se copie très bien et je ne pense pas qu'il y ait un coût rédhibitoire.
Donc, pourquoi ne pas avoir une map par valeur : std::map<std::string,user> ?

---

Il y'a une grosse difference en memoire entre un pointeur et une reference ?
On m'a explique qu'une reference etait un pointeur qui ne pouvait etre NULL.

Citation:

---

Si tu veux vraiment mettre des pointeurs, pourquoi ne pas avoir mis des pointeurs intelligent ?

---

Je viens de "decouvrire" la notion de pointeur intelligent, je vais pousser un peu le delire :)

Citation:

---

De la même façon, si c'est pour mettre des accesseurs aux membres de ta classe, et bien, rends carrément public ces membres. Ca ne sert à rien de les mettre en privé si c'est pour ajouter des getter/setter.

---

Question de convention scolaire actuellement, mais surtout question de logique au cas ou un tiers reprendrait mon code. :mrgreen:

Salut,

Citation:

---

Envoyé par nonoxen

J'uilise celui par default de visual c++ je ne pourrais pas te donner le nom comme ca, que cette methode marche m'egare neamoins je pense simplement que mon u->getLog() doit etre different d'une string entre double quotes.
(A cause des constante ?)

---

A priori, sans tester, la version Visual 6 pourrait peut être expliqué le problème. Pas les versions plus récentes.

Citation:

---

Envoyé par nonoxen

Il y'a une grosse difference en memoire entre un pointeur et une reference ?
On m'a explique qu'une reference etait un pointeur qui ne pouvait etre NULL.

---

Pas par pointeur ni par référence, par valeur : std::map<std::string, user>.

Citation:

---

Envoyé par nonoxen

Je viens de "decouvrire" la notion de pointeur intelligent, je vais pousser un peu le delire :)

---

:ccool:
Cf le tuto de Loïc Joly : Présentation des pointeurs intelligents en C++

Citation:

---

Envoyé par nonoxen

Question de convention scolaire actuellement, mais surtout question de logique au cas ou un tiers reprendrait mon code. :mrgreen:

---

:koi:
Il n'est jamais trop tard pour changer de mauvaises habitudes :mouarf:.
Si tes membres ont des get/setter, alors il n'y a aucun intérêt à les garder privés : mets les publics et supprimer les get/setter. C'est cohérent quand ta classe ressemble plus à une structure 'POD' (disons, 'à la C') qui se contente de regrouper des données sans vraiment avoir de comportement. Si ta classe est une 'vraie' classe, alors elle doit avoir un niveau d'abstraction (interface publique) qui soit indépendante des variables qu'elle contient. En ce sens, les getter/setter traduisent une mauvaise conception.

Citation:

---

Envoyé par 3DArchi

Il n'est jamais trop tard pour changer de mauvaises habitudes :mouarf:.
Si tes membres ont des get/setter, alors il n'y a aucun intérêt à les garder privés : mets les publics et supprimer les get/setter. C'est cohérent quand ta classe ressemble plus à une structure 'POD' (disons, 'à la C') qui se contente de regrouper des données sans vraiment avoir de comportement. Si ta classe est une 'vraie' classe, alors elle doit avoir un niveau d'abstraction (interface publique) qui soit indépendante des variables qu'elle contient. En ce sens, les getter/setter traduisent une mauvaise conception.

---

Une petite précision:

C'est la présence des deux qui traduit une mauvaise conception.

Dans certains cas, n'avoir qu'un getter est "cohérent" avec les services que l'on attend de la classe: une classe Personne doit pouvoir répondre à des question comme "quel est ton nom" ou "quel est ton prénom"

Par contre, cette classe personne ne devra, quoi qu'il advienne, normalement pas permettre de modifier la variable qui représente le nom ou le prénom: il n'y a que peu de raisons pour que Durand André finisse par s'appeler Cauet Roberta ;)

Dans d'autres cas (les fabriques :question:) il peut être "cohérent" de permettre à une seule classe d'aller modifier une variable privée d'une des classes, tout en voulant malgré tout que certaines vérifications soient effectuées avant d'accepter ces modifications.

Dans ce cas, un getter peut être créé, mais étant donné qu'il ne devrait être appelé que par une classe particulière, il est sans doute préférable de le déclarer en visibilité privée, et de déclarer la classe autorisée comme amie.

Mais, autrement, 3DArchi a tout à fait raison ;)

A vous entendre les getteurs et les setteurs servent a repondre a des questions de conceptions bien precises.
Mon developpement n'etant pas termine il me semble alors bien plus judicieux de passer par des getteurs et setteurs comme ca le jour ou ma classe user change mes getteurs et setteurs restent et ne genent personne.
En revanche la conception de ceux ci pourront changer...

Non ?

Non... surement pas...

Tu dois penser à tes classes comme étant des objets capables de rendre des services, autrement dit, de réagir à certains message ou d'en émettre à destination d'autres objets.

Les données membres ne sont là que pour permettre à tes objets de rendre ces services.

En ce qui concerne les setters, il n'est, le plus souvent, absolument pas cohérent de permettre à n'importe quoi d'aller modifier ces données membres:

Imaginons un réservoir d'essence... les deux données principales qui le composent sont sa capacité et la quantité d'essence qu'il contient.

Il n'est absolument pas cohérent de permettre à quoi que ce soit de modifier capacité d'un réservoir donné une fois qu'il a été créé.

Il n'est pas non plus cohérent de permettre la modification de la quantité d'essence qu'il contient, par contre, le service que l'on attend de lui, c'est de réagir à un ordre proche de "rajoute (xxx) litres".

Et, c'est à ce comportement de déterminer si, oui ou non, il est possible de rajouter ces xxx litres.

De même, pour les getters, il y a deux choses à prendre en ligne de compte:
La première, c'est qu'il est rarement intéressant de récupérer la donnée membre telle quelle: la quantité d'essence dans le réservoir n'est pas intéressante en tant que telle.

Par contre, ce qui nous intéresse, c'est de connaitre le niveau du réservoir, qui sera en réalité calculé en effectuant le quotient de la quantité d'essence qu'il contient par sa capacité maximale.

Et on peut également s'attendre à ce que le réservoir envoie un message "attention, nous sommes sur la réserve" quand la quantité d'essence qu'il contient descend en dessous d'un certain seuil.

La deuxième chose à prendre en compte est la loi demeter.

Pour faire simple, si une classe A s'adresse à une classe B et que cette classe B utilise en interne une classe C, il n'y a aucune raison pour que la classe A ait accès à la classe C.

Or, les getter/setter donnent, justement, accès à la classe C qui se trouve dans la classe B, non seulement à la classe A, mais également à toute classe qui manipule la classe B...

Reprenons l'exemple de notre réservoir d'essence, et mettons le dans une voiture (c'est une des places auxquelles il se sent particulièrement utile :D):

Tout le monde sait parfaitement bien qu'une voiture est, entre autres, composée d'un réservoir d'essence...

Mais, dans la majorité des cas, personne n'a strictement rien à faire d'y avoir accès: ce qui nous intéresse, ce sont les trois comportements dont j'ai parlé (ajouter (xxx) litres, connaitre le niveau, réagir au message "je suis sur réserve") qui devraient ici être "déportés" au niveau de la voiture.

Comprends tu maintenant en quoi les getters/setters sont mauvais :question:

Si tu dois rajouter quelque chose à ta classe, ce sera plus certainement un comportement donné et clairement défini (ajouteCarburant ), quitte à rajouter une variable qui permet de rendre le comportement cohérent, que de rajouter une variable et les getters / setter correspondants ;)

[EDIT]PS: j'ai, à vrai dire, oublié un comportement qui ne doit être accessible qu'au départ de la voiture: celui qui consiste à retirer xxx cl (ml:question:) chaque fois qu'un cylindre est rempli...