Pointeur NULL dans conteneur c++

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...