Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Retour par référence d'un pointeur
Bonjour à tous
Voici un exemple de code pour illustrer mon souci
Je ne vois pas trop bien ce que fait ce type de retour, à quoi ça sert et pourquoi ne pas simplement retourner un pointeur ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Merci d'avance
Parce que les références ont plus de restrictions d'utilisations, les rendant plus sûres.
Ok merci beaucoup c'est beaucoup plus clair.
Mais si le pointeur est nul, on retourne une référence invalide, ce qui n'est pas censé arriver.
En fait, arriver a ce genre d'accesseur est mauvais signe.
Dans le doute j'aurais quand même mis un pointeur ne serait-ce que pour que l'utilisateur du code soit prévenu qu'il soit potentiellement null.
Si ça ne dois de toutes façons pas arriver, alors il y a un problème autre part....ou alors c'est un objet qui construit une donnée via new ou malloc et qui fournis une référence a l'exterieur. Si c'est le cas, une assertion serait bienvenue je pense.
Je vois pas où est le problème dans cette interface...
L'InputManager peut utiliser l'héritage et être appartenu par l'objet. Ou alors il peut changer. Ce qui justifie parfaitement d'utiliser un pointeur plutôt qu'une référence en interne.
Il n'est néanmoins pas nécessaire de fournir à l'utilisateur un pointeur, une référence suffit.
Qu'est-ce qui te permet de dire que le pointeur ne pointera pas toujours vers un objet valide ? C'est un invariant plutôt facile à garantir...Dans le doute j'aurais quand même mis un pointeur ne serait-ce que pour que l'utilisateur du code soit prévenu qu'il soit potentiellement null.
Ce que je dit, c'est que ça manque de vérifications, globalement, et donc même si tu peux pas être certain que l'objet fourni est valide, au moins tu vas pas t'étonner de te retrouver avec des références nulles.Qu'est-ce qui te permet de dire que le pointeur ne pointera pas toujours vers un objet valide ? C'est un invariant plutôt facile à garantir...
On peut toujours "asserter" les références pour vérifier si elles sont nulles, mais personellement je préfère garantir que le pointeur dont est issu la référence n'est pas null et a ce moment là seulement fournir une référence.
Il n'y a pas besoin de faire un assert.
Le pointeur est initialisé dans le constructeur et libéré dans le destructeur.
Le RAII garantit déjà qu'il sera toujours initialisé.
Je ne vois pas le code qui garanti ce que tu décris : je ne vois qu'un pointeur dont on fournis l'objet pointé par référence via une méthode. Rien dans ce qui est montré dans l'exemple n'indique que le pointeur est forcément valide a l'appel.
Même si évidemment je suis d'accord sur le principe, c'est le code décris au dessus, sans autre info, que j'aurais bardé de vérifications.
+1Envoyé par Klaim
.
Bien sûr qui si le code autour est bien fait le pointeur ne devrait pas se retrouver NULL (et encore...). Mais comme personne, même les meilleurs, n'est à l'abri d'une coquille, mieux vaut empêcher toute configuration bancale qui mènerait à un plantage pur et simple du type Violation d'accès à l'adresse 0xC000000005, l'adresse ne peut être "Read".
Salut,
Je rejoins klaim sur ce coup làLe problème vient du fait que le RAII n'est jamais qu'un concept que chacun reste libre de respecter... ou non...
Si toi et moi le respectons, je peux t'assurer que tu serais surpris du nombre de personnes qui n'en ont même jamais entendu parler
Il me semble donc malgré tout dangereux de se baser sur le seul principe du "Le RAII assure que les membres sont initialisés" pour se dire que le code peut être laissé en l'état sans avertissement préalable.
En outre, nous n'avons aucune information sur ce que représente ce InputManager et par conséquent ce vers quoi point ce m_InputManager
Le nom nous inciterait presque à croire qu'il s'agit d'une variable statique, auquel cas, nous aurions affaire à un singleton et la méthode devrait assurer l'allocation dynamique du membre s'il vaut NULL.
Mais il peut aussi s'agir de l'élément "parent" dans une structure "arborescente" ou de la référence vers l'observateur dans une structure observée ou ...
S'il s'agit de l'élément parent d'une structure aborescente, il y a le problème de l'élément racine... qui n'a plus de parent, et pour lequel le pointeur pointera alors sur NULL... et la méthode renverra une référence invalide.
S'il s'agit de la référence sur l'observateur dans une structure observée, il ne nous est pas possible de déterminer si la délégation des tâches a correctement été effectuée, et, par conséquent si le RAII a bel et bien été respecté lui aussi.
Bref, si je t'accorde que l'on peut se baser sur le fait que le RAII donne toutes les assurances chez une personne respectant les "règles de bonne conduite" d'un programmeur C++, la question qui reste en suspend est "est-on face à une telle personne".
Sans vouloir le moins du monde me montrer désobligeant envers Funky Tech, le niveau de sa question m'incite à penser qu'il s'agit de quelqu'un qui débute (on est tous passé par là, hein
Mais c'est pas parce qu'on ne sait pas si le RAII a été appliqué qu'il faut forcément imposer toutes les vérifications...
Dans les deux cas, c'est soit faire un excès de confiance au posteur du code, soit ne pas lui faire confiance !
La bonne solution était de demander au posteur le contexte...
En tout cas, la classe est clairement un singleton ou un singleton-like.
Oui, mais non...
L'un dans l'autre, je serais bien plus rassuré s'il n'y avait ne serait-ce qu'une assertion de manière à assurer au moins le fait que m_InputManager ne soit pas nul en mode débug
Les politiciens ont décidé d'appliquer très souvent le fameux "principe de précaution"...Dans les deux cas, c'est soit faire un excès de confiance au posteur du code, soit ne pas lui faire confiance !
Pour ma part, j'estime que ce principe doit prévaloir quand tu n'a qu'une partie de code qui ne te permet pas de te faire une idée précise de la manière dont les choses sont réellement mises en oeuvre...
Au pire, tu obtiens alors une réponse proche de "ne t'en fais pas, c'est bel et bien ainsi que j'ai envisagé les choses"
C'est pas fauxLa bonne solution était de demander au posteur le contexte...
[/QUOTE]En tout cas, la classe est clairement un singleton ou un singleton-like.[/QUOTE]
Ce qui tendrait à ajouter du poids au fait qu'il serait surement intéressant de placer le test, non
Mon propos était juste de dire que dans les deux cas, vous agissiez tête baissée, que vous soyiez prudent ou téméraire.
Oui, si c'est un singleton qui est initialisé et créé dès la première utilisation, il faut faire un test.Ce qui tendrait à ajouter du poids au fait qu'il serait surement intéressant de placer le test, non
Si c'est un singleton-like qui doit être explicitement créé et détruit en début et fin de programme, alors juste une assertion.
Non ma classe n'est pas du tout un singleton. En fait je possède une classe System qui elle est un singleton, elle rescence tous les managers (input, world, sound...) qui sont simplement des pointeurs sur chaqune de ces classes.
J'ai juste posé la question parce que j'ai vu ce code dans un moteur de jeu, et comme je n'ai jamais pratiqué cette technique je m'intérroge
Donc qu'elle est la meilleure solution selon vous sachant que j'assert mon pointeur dans System::Initialise() ?
Si tu a la certitude que ton InputManager (et tous les autres, d'ailleurs) est correctement initialisé, rien ne t'empêche effectivement de renvoyer "ce qui est pointé par m_InputManager" sous la forme d'une référence... à toi de voir s'il faut le faire sous forme constante ou non.
Comme on l'a indiqué tout au cours du débat, le gros risque (que tu peux éliminer par le reste du code), c'est que la méthode renvoie une référence invalide.
Une fois ce risque éliminé, tu peux foncer
[EDIT]par contre la question que tu pourrais te poser estmais ca, ca va dépendre de ta sensibilité propreest-il réellement opportun que mon singleton dispose du InputManager sous la forme d'un pointeur vers celui-ci
Ok merci pour toutes ces réponses, c'est plus que ce que j'en attendait
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager