référence retournée par une méthode = objet à ne pas garder

Bonjour,

J'ai entendu dire que lorsqu'une référence vers un attribut est retournée par une méthode, le programmeur C++ sait que c'est un objet à ne pas garder. Je veux dire par là qu'il faut la récupérer dans un bloc, l'utiliser dans ce bloc puis la relacher à la sortie du bloc et ne surtout pas la conserver dans un poiteur (ptr = &ref).

Cela me serait bien utile dans les cas où un objet donne une const ref vers un de ses attributs (ex: un buffer de pixel), mais qu'il ne veut pas qu'on la conserve pendant plus d'un appel de fonction (ex: qu'on ne conserve la référence vers le buffer que le temps de l'enregistrer dans un fichier), d'autant plus que la référence sera invalide une fois l'objet détruit.

Qu'est que vous en dites?
Est ce que vous voyez les références retournées par des méthodes de la même façon???

Merci de vos réponses!!! :ccool:

Bonjour,

une référence est un pointeur, la durée d'utilisation d'une référence est donc limité à la durée de vie de l'élément référencé.

s'il s'agit d'une référence vers un attribut d'instance alors la durée d'utilisation est celle de l'instance, si c'est un attribut de classe (static) la chose est immortelle

Citation:

---

Envoyé par nonozor

Bonjour,

J'ai entendu dire que lorsqu'une référence vers un attribut est retournée par une méthode, le programmeur C++ sait que c'est un objet à ne pas garder. Je veux dire par là qu'il faut la récupérer dans un bloc, l'utiliser dans ce bloc puis la relacher à la sortie du bloc et ne surtout pas la conserver dans un poiteur (ptr = &ref).

Cela me serait bien utile dans les cas où un objet donne une const ref vers un de ses attributs (ex: un buffer de pixel), mais qu'il ne veut pas qu'on la conserve pendant plus d'un appel de fonction (ex: qu'on ne conserve la référence vers le buffer que le temps de l'enregistrer dans un fichier), d'autant plus que la référence sera invalide une fois l'objet détruit.

Qu'est que vous en dites?
Est ce que vous voyez les références retournées par des méthodes de la même façon???

Merci de vos réponses!!! :ccool:

---

Etant donné que ton premier message n'est pas très clair, j'aiu peur de répondre à coté. Néanmoins, renvoyer une référence vers un attribut ne pose aucun problème "technique "tant que l'objet référéncé est valide;
Après, il faut se poser la question de l'utilité renvoyer une référence non constante sur un objet et de la garder. Dans certains cas, c'est utile (vector) dans d'autres ca peut être problématique. A voir.

Enfin la gestion de la validité est une autre problématique qui doit s'examiner en fonction de ton code.

Citation:

---

Envoyé par bruno_pages

une référence est un pointeur, la durée d'utilisation d'une référence est donc limité à la durée de vie de l'élément référencé.

---

Non, pointeurs et références n'ont pas la même sémantique d'utilisation. Un pointeur peut amener à l'arithmétique des pointeurs en cachant à tableau, peut être réalloué, ... A l'inverse une référence n'est qu'un autre nom pour un objet, elle ne peut donc ni être dissocier ni nulle (sauf trick sur l compilo). Après qu'en interne, une référence utilise un pointeur, possible mais on s'en tape.

Citation:

---

Envoyé par Davidbrcz

Non, pointeurs et références n'ont pas la même sémantique d'utilisation.

---

curieuse réaction, car je n'ai jamais dit qu'ils avaient la même sémantique d'utiilsation

Citation:

---

qu'en interne, une référence utilise un pointeur, possible mais on s'en tape.

---

et non justement, car on ne peut pas passer outre tout ce que cela implique

... a croire que le but de la réponse était juste de polémiquer :koi:

Citation:

---

Envoyé par bruno_pages

curieuse réaction, car je n'ai jamais dit qu'ils avaient la même sémantique d'utiilsation


et non justement, car on ne peut pas passer outre tout ce que cela implique

... a croire que le but de la réponse était juste de polémiquer :koi:

---

Non, de démontrer la fausseté de ta réponse : "une référence est un pointeur" c'est tout simplement faux car justement ils n'ont pas la même sémantique d'utilisation.

Citation:

---

et non justement, car on ne peut pas passer outre tout ce que cela implique

---

On peut s'en passer, il suffit de regarder la norme pour savoir les règles d'utilisation et de validité d'une référence. Le pointeur en dessous, c'est de la cuisine interne.

Bonjour,

ma question ne portait pas tellement sur la nature des références mais sur leur utilisation. Plus précisément, lorsqu'une référence vers un attribut d'instance est renvoyée par une fonction, est ce que le fait que ce soit une référence et non un pointeur qui soit passé est un message "hého, tu peux utiliser cette référence dans le même bloc où tu l'as demandé, mais tu ne dois pas la conserver".

S'il y a ce message, ça me serait bien utile.

Ce n'est pas une question de "techniquement, tu peux garder une référence, elle sera valide tant qu'est valide le référencé", mais plutot de "par convention entre codeurs C++, lorsqu'on passe un attribut par référence, c'est qu'il ne faut pas conserver de lien vers cet attribut".

Par exemple, avec la classe Image, je voudrais pouvoir passer son buffer de pixels à un objet Enregistreur pour qu'il l'enregistre dans un fichier. Je peux donc faire une fonction GetPixels qui sera appelée par Enregistreur.

Code:

---

1 2 3 4 5 6 7

class Image { public: char * GetPixels(){return pixels;} protected: char * pixels; }

---

Cependant, rien n'empèche Enregistreur de conserver dans un de ses attributs le pointeur donné par GetPixel, pour par exemple enregistrer l'image toutes les 30 milisecondes.

Cela est embettant si je ne veux pas qu'il le conserve, mais plutot qu'il le redemande à chaque fois qu'il re-enregistre.

J'ai entendu dire que si on ne veut pas qu'il conserve pixels, il faut renvoyer pixels dans une référence. Car lorsqu'un attribut est renvoyé par une référence, donc ici char * & GetPixels(), le programmeur saurait par expérience qu'il ne faut pas essayer de conserver le référencé. Ainsi, si un programmeur codait Enregistreur et qu'il voyait que Image propose char * & GetPixels() pour accéder aux pixels, il saurait qu'il ne faut pas conserver pixels.

Est ce que vous voyez les choses de la même façon?
Est ce que vous avez une autre méthode pour faire passer le message "hého, je te donne un lien vers un de mes attributs, mais tu ne dois pas le conserver"???

Bonjour,

Citation:

---

Envoyé par nonozor

Est ce que vous avez une autre méthode pour faire passer le message "hého, je te donne un lien vers un de mes attributs, mais tu ne dois pas le conserver"???

---

J'ai envie de dire, si il le garde quelle importance ? si tu ne veux pas qu'il le conserve et bien... ne le conserves pas :P.

Ton exemple est un peu particulier car tu utilise un tableau a la C, donc que se soit par valeur ou par adresse que tu passes les arguments ça ne changera pas grand chose, car sa sera les mêmes adresses qui seront pointées. La seule chose que tu peux faire c'est rendre ton tableau constant.

Pour les références c'est un peu un "sucre syntaxique" dans le sens ou tu peux faire la même chose (et même plus ce qui les rend sémantiquement différentes) avec des pointeurs. On les utilise beaucoup pour éviter les copies couteuses lors de passage de paramètres, mais après elle ne font pas passé de message particulier aux utilisateurs (si ce n'est que la variable peut être modifié quant on la passe en argument par référence non constante).

Salut,

Citation:

---

Envoyé par nonozor

Est ce que vous voyez les choses de la même façon?

---

Non.
Que le type retour soit par référence ou par pointeur, je vais me préoccuper de la durée de validité du retour pour ne pas avoir une référence ou un pointeur invalide.
Quand choisir une référence ou un pointeur ? Personnellement, j'ai tendance à penser que si tu renvois un pointeur, alors tu peux renvoyer NULL. Alors qu'avec une référence j'aurai forcément un objet valide (et éventuellement une exception si la fonction ne peut retourner un objet valide). Donc, j'utilise un retour par pointeur si retourner NULL est un scénario acceptable de l'utilisation de la fonction. Et j'utilise une référence si je veux toujours avoir un objet valide en retour de la fonction.
Après que je conserve ou non cette référence/adresse n'est pas lié à ça mais bien au contrat de validité que me propose l'interface.

Citation:

---

Est ce que vous voyez les choses de la même façon?

---

Oui.

Mais ça n'est qu'une partie des critères de choix entre pointeur et référence.

Citation:

---

Envoyé par nonozor

ma question ne portait pas tellement sur la nature des références mais sur leur utilisation. Plus précisément, lorsqu'une référence vers un attribut d'instance est renvoyée par une fonction, est ce que le fait que ce soit une référence et non un pointeur qui soit passé est un message "hého, tu peux utiliser cette référence dans le même bloc où tu l'as demandé, mais tu ne dois pas la conserver".

---

Que tu retournes une référence ou un pointeur, il faut documenter la durée de vie de l'objet retourné. Mais rien n'interdit l'introduction dans les règles de codage du projet d'une convention spécifiant que le choix référence/pointeur implique quelque chose sur celle-ci. Il n'y pas a pas de conventions générales à cet effet. Mais ce genre de conventions doit tenir compte d'autres facteurs. Et le choix pointeurs/références ne permet pas toutes les nuances désirables (qui est chargé de libérer la mémoire par exemple?). Pour les introduire, tu peux jouer avec des pointeurs intelligents.

Citation:

---

Est ce que vous avez une autre méthode pour faire passer le message "hého, je te donne un lien vers un de mes attributs, mais tu ne dois pas le conserver"???

---

Pointeurs intelligents. Mais il ne faut pas non plus arriver à sur-concevoir ce genre de conventions. Dans ce cas, elles finissent plus ou moins rapidement par être mal employées car mal maîtrisées, voire ne plus être employées du tout et la situation est pire que si elles n'avaient jamais été proposées.