Discussion :

[kinta]

Est ce mieux de déclarer

comme ceci (retour par référence)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mon_objet *Mon_objet::function ();

ou comme cela (retour par pointeur)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mon_objet &Mon_objet::function ();

J'ai l'intime conviction que c'est la même chose !?
Peut être est ce mieux par référence !?

[Médinoc]

C'est la même chose, sauf au niveau syntaxe, et aussi, si c'est un objet alloué dynamiquement, on risque d'avoir un peu de mal à le supprimer avec delete.

Personnellement, toute fonction qui retourne un nouvel objet, je lui fait retourner un pointeur, car c'est ainsi que new se comporte.
Après, si la fonction retourne une référence vers un objet existant (dans l'objet dont la fonction est membre, ou bien passé en paramètre), ça dépend...
Originaire du C, je m'en sors mieux avec les pointeurs, réservant généralement les références aux operator. Mais d'autres ont la philosophie inverse : "Références partout, sauf quand le pointeur est indispensable". Et pour une fonction new-like, je qualifie arbitrairement le pointeur d'indispensable.

[bigquick]

Et pour une fonction new-like, je qualifie arbitrairement le pointeur d'indispensable.

Entièrement d'accord. Et vice-versa, une fonction qui renvoie un pointeur me laisse penser qu'il vient d'être fraichement alloué, et qu'il faut que je le delete à la fin de mon utilisation.

Il y a aussi le cas des fonctions qui peuvent retourner un objet, ou rien du tout, comme une recherche dans un conteneur. En C on penserait tout de suite à utiliser les pointeurs (NULL pour le cas "non trouvé"), mais en C++ on peut aussi utiliser:
un retour par référence, ou un lancement d'exception le cas écheant, si toutefois les exceptions sont activées
un retour d'iterateur, qui peut être invalide
...

Enfin le mieux reste de bien documenter ses méthodes, comme ça pas de confusion possible sur l'objet retourné !

[BigNic]

Et pour une fonction new-like, je qualifie arbitrairement le pointeur d'indispensable.

tout à fait d'accord aussi. Et c'est pour ça que je met des références partout, sauf pour certains cas dont celui-là. Comme ça quand tu croise un pointeur, tu sais qu'il faut pas faire n'importe quoi avec et peut-être penser à le libérer.

[loufoque]

De manière générale, les pointeurs sont à éviter.
Utilise les que si tu en as besoin.

A priori ton truc ce serait plutôt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mon_objet Mon_objet::function ();

À part si tu veux effectivement retourner une référence vers une variable membre ou autre.

[bigquick]

A priori ton truc ce serait plutôt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mon_objet Mon_objet::function ();

À part si tu veux effectiver retourner une référence vers une variable membre ou autre.

En effet il faut clairement se poser la question. On arrive ici à question de conception et non de style. En gros, que souhaites-tu retourner ? Une copie modifiable ? Un simple accès vers la variable ? En lecture / écriture ?

Je pense qu'une copie systematique de l'objet est dommage car souvent superflue. Retourner une référence constante peut solutionner 2 des problèmes: la copie modifiable et l'accès en lecture:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
const Objet&   MaClasse::getObjet();
 
{
       const Objet& acces = getObjet();
             Objet  copie = getObjet();
}

Ca pousse la personne à se demander si elle veut vraiment copier l'objet ou non, puisque à moins d'expliciter cette copie, le compilateur refusera les appels vers des méthodes non constantes.

-

Sinon, petite question, j'ai vu beaucoup de biliothèques qui définissaient à la fois un accesseur par référence et un accesseur par référence constante pour le même objet. Est-ce que vous voyez des avantages particuliers ?

[HanLee]

A priori ton truc ce serait plutôt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mon_objet Mon_objet::function ();

À part si tu veux effectiver retourner une référence vers une variable membre ou autre.

En effet il faut clairement se poser la question. On arrive ici à question de conception et non de style. En gros, que souhaites-tu retourner ? Une copie modifiable ? Un simple accès vers la variable ? En lecture / écriture ?

Je pense qu'une copie systematique de l'objet est dommage car souvent superflue. Retourner une référence constante peut solutionner 2 des problèmes: la copie modifiable et l'accès en lecture:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
const Objet&   MaClasse::getObjet();
 
{
       const Objet& acces = getObjet();
             Objet  copie = getObjet();
}

Ca pousse la personne à se demander si elle veut vraiment copier l'objet ou non, puisque à moins d'expliciter cette copie, le compilateur refusera les appels vers des méthodes non constantes.

-

Sinon, petite question, j'ai vu beaucoup de biliothèques qui définissaient à la fois un accesseur par référence et un accesseur par référence constante pour le même objet. Est-ce que vous voyez des avantages particuliers ?

Pour des valeurs de retour, il me semble qu'en déclarant simplement sans référence, il y a des compilateurs qui savent optimiser, en évitant la copie, c'est à dire en faisant comme si l'objet créé sur la pile était la valeur affectée par la valeur de retour de la fonction.

Enfin bon, il faut bien connaître ses compilateurs pour oser faire ça.

[bigquick]

Oui en effet j'en ai entendu parler ! Mais comme tu dis, si c'est vrai sur un compilateur donné, il faudra peut-être tout refaire à la main si on change de compilateur. Dans ce cas là je suis d'avis de donner un coup de pouce au compilo en lui mettant des références "là où il faut", et des petits mot-clés "const" partout

[reggae]

Je suis tout à fait d'accord avec bigquick concernant l'aspect "conception" qui vise à ne pas perdre de temps en copiant X fois la variable, mais en en en économisant en passant, quand cela est possible, par référence(si possible constante)...

Mais il faut avouer que j'aime bien utiliser les pointeurs, pour des raisons évoquées plus haut...


Effectivement je trouve un peu riqué de se fier au avantage de son compilo, car l'obligation d'en changer risquerait de demander beaucoup plus de temps que prévu...

[HanLee]

Oui en effet j'en ai entendu parler ! Mais comme tu dis, si c'est vrai sur un compilateur donné, il faudra peut-être tout refaire à la main si on change de compilateur. Dans ce cas là je suis d'avis de donner un coup de pouce au compilo en lui mettant des références "là où il faut", et des petits mot-clés "const" partout

Oui, d'ailleurs c'est tellement pas connu que j'm'en méfie et que j'fais comme toi.

Mais parfois j'aimerais bien aller à l'essentiel, et éviter de perdre du temps comme ça.

[JolyLoic]

Sinon, petite question, j'ai vu beaucoup de biliothèques qui définissaient à la fois un accesseur par référence et un accesseur par référence constante pour le même objet. Est-ce que vous voyez des avantages particuliers ?

Oui, si l'objet n'est pas constant, un accesseur non constant par référence non constante permettra de le modifier. S'il est constant, l'accesseur constant par référence constante ne le permettra pas.

[Luc Hermitte]

Sinon, petite question, j'ai vu beaucoup de biliothèques qui définissaient à la fois un accesseur par référence et un accesseur par référence constante pour le même objet. Est-ce que vous voyez des avantages particuliers ?

Oui, si l'objet n'est pas constant, un accesseur non constant par référence non constante permettra de le modifier. S'il est constant, l'accesseur constant par référence constante ne le permettra pas.

Cas qui fait se demander si le design est vraiment bon ...

Sinon comme d'autres. Par défaut je prends les références (constantes) quand c'est possible. Des valeurs quand le résultat est construit et que l'on a bien une sémantique de valeur, ou que la copie est bien définie et excessivement peu couteuse (genre < 2-3 ints). Des pointeurs quand il faut pouvoir renvoyer null ou créer une nouvel élément ; et dans ce dernier cas, je préfère de plus en plus souvent l'auto_ptr<> qui lève toute ambiguité quant à ce qui se passe dans la fonction. Les itérateurs pour les fonctions de recherche internes: privées ou protégées.

[kinta]

Merci bien à tous pour ces conseils.

[bigquick]

Oui, si l'objet n'est pas constant, un accesseur non constant par référence non constante permettra de le modifier. S'il est constant, l'accesseur constant par référence constante ne le permettra pas.

C'est à dire qu'ils ont écrit les 2 accesseurs "au cas ou" ? (je parle bien du même objet, qui ne peut donc pas être constant et non-constant à la fois ).

Cas qui fait se demander si le design est vraiment bon ...

Aie, c'est justement le cas dans la bibliothèque OpenSceneGraph, qui avait une réputation plutôt correcte niveau design je crois. Dommage

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
const Drawable* osg::Geode::getDrawable (unsigned int i) const
      Drawable* osg::Geode::getDrawable (unsigned int i)

[Médinoc]

Un même objet ne peut pas être constant et non-constant à la fois, mais deux pointeurs/références différents sur cet objet peuvent être l'un const, l'autre non...

Ainsi, c'est courant de passer une référence const d'objet à une fonction qui ne le modifie pas...
Cette fonction peut alors utiliser les accesseurs const, mais pas les accesseurs non-const.
Cela garantit que la fonction possède un accès en lecture à l'objet.

D'autres fonctions, elles peuvent avoir besoin d'un accès en écriture...



Mais il est vrai que les accesseurs par références peuvent être remplacés par des getters/setters...
Mais c'est souvent utilisé pour les accès par opérateur, notamment l'opérateur [].

[loufoque]

Enfin bon, il faut bien connaître ses compilateurs pour oser faire ça.

Les auteurs du C++ standard recommendent de faire "ça".
C'est au compilateur de se débrouiller pour faire en sorte que le code final soit optimisé.

[bigquick]

Enfin bon, il faut bien connaître ses compilateurs pour oser faire ça.

Les auteurs du C++ standard recommendent de faire "ça". C'est au compilateur de se débrouiller pour faire en sorte que le code final soit optimisé.

Euh, je suis d'accord pour laisser au compilateur le soin d'optimiser le bas niveau; je trouve ça inutile de rendre le code illisible pour optimiser 3 lignes d'une fonction, alors qu'il y a surement des goulots d'étranglement ailleurs ... (je ne sais plus qui donnait l'exemple d'un bubblesort optimisé par des décalages de bits )

Pour des valeurs de retour, il me semble qu'en déclarant simplement sans référence, il y a des compilateurs qui savent optimiser, en évitant la copie, c'est à dire en faisant comme si l'objet créé sur la pile était la valeur affectée par la valeur de retour de la fonction.

Je ne suis pas sur d'avori vraiment compris ce que HanLee voulait dire.... Mais si c'est que certains compilateurs remplacent des retours par copie par des référence si les copies ne sont pas modifiées, alors non je ne suis pas d'accord pour laisser ce travail au compilateur

On lui facilite beaucoup la tache en faisant ce petit effort soi-même (est-ce que j'ai vraiment besoin d'une copie ?). Et à mon avis, ça nuit à la lisibilité du code puisqu'une référence constante prévient clairement "je te donne un accès, mais en lecture seule" (le client pourra faire une copie locale si il y tient). Alors qu'un retour par copie se lirait plutôt "tiens, voilà une copie pour en faire ce que tu veux". On sent bien les 2 approches différentes.

Enfin, c'est surement une question de goûts