Discussion :

[hydrolyre]

Bonjour, je me pose une questions sur les références :

Doit-on toujours les mettre pour les types de base. Je m'explique.

Si dans une class on a un ascensseur qui renvoi un int, qu'est ce qu'il faut mieux faire :

1)

Code :

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

1
2
 
int Get_Int() const;

ou
2)

Code :

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

1
2
 
const int &Get_Int() const;

Et si dans une fonction on utilise des types de base, il vaut mieux faire

Code :

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

1
2
 
void Add( int a, int b );

ou

Code :

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

1
2
 
void Add( const int & a, const int & b);

Merci

[Arzar]

Bonjour,
Une recommandation qui fait autorité en C++ vient de "Effective C++" par Scott Meyers (un des livres de chevet de tout bon programmeur C++ )

Pour le choix passage par valeur/par const ref :

Item 20: Prefer pass-by-reference-to-const to pass-by-value

Things to Remember

Prefer pass-by-reference-to-const over pass-by-value. It's typically more efficient and it avoids the slicing problem.

The rule doesn't apply to built-in types and STL iterator and function object types. For them, pass-by-value is usually appropriate.

Par contre, fait très attention avec des fonctions comme : const Truc& fonction(); car souvent :

Item 21: Don't try to return a reference when you must return an object

Things to Remember

Never return a pointer or reference to a local stack object, a reference to a heap-allocated object, or a pointer or reference to a local static object if there is a chance that more than one such object will be needed. (Item 4 provides an example of a design where returning a reference to a local static is reasonable, at least in single-threaded environments.)

Il y a bien sur des explications pour justifier ces recommandations, mais elles sont vraiment longues et détaillées, donc pas vraiment adaptées à un forum...

[koala01]

Salut,

Il n'y a pas vraiment d'intérêt à passer les types primitifs ( bool, char, short, int, long, (long long), float, double, (long double) ) ou équivalent (valeur énumérées) par référence, simplement parce que la copie se fait rapidement et ne demande pas énormément de ressources mémoire.

Le seul cas où l'on peut envisager de passer un de ces types par référence (non constante) serait celui où une modification de la valeur effectuée dans la fonction appelée devrait se répercuter dans la fonction appelante (et où la valeur de retour serait déjà utilisée pour autre choses).

Pour les type de base, il est donc souhaitable (si les modifications apportées dans la fonction appelée ne doivent pas être répercutées dans la fonction appelante) d'utiliser le passage par valeur:

Code :

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

void foo( int a, int b, double d);

Par contre, pour les types définis par l'utilisateur (à l'exception cependant des valeurs énumérées, qui rentrent dans la catégorie "assimilés à un type primitif"), il faut savoir que la copie revient à doubler l'espace mémoire nécessaire pour représenter la donnée (qui apparait une fois dans la fonction appelante et une autre fois dans la fonction appelée), et que cela revient, le plus souvent, à appeler l'ensemble des constructeurs par copie des membres qui la composent...

Le tout, sans oublier les risques encourus si l'un des membres de la donnée venait à être un pointeur.

C'est la raison pour laquelle le conseil de base est de passer les types définis par l'utilisateur sous la forme de références, afin d'éviter la copie

Par dessus ce conseil, il faut rajouter le conseil de rendre constant tout ce qui n'a pas vocation à être modifié:

Si tu passe une donnée (dont le type est une structure, une classe ou une union) à une fonction qui n'a pas pour vocation de modifier cette donnée, il est préférable de la passer par référence constante

Enfin, au niveau de la valeur de retour, le conseil de base est de ne jamais renvoyer par référence un objet non constant...

En effet, si tu renvoie une référence non constante sur un membre de ta classe, tu donne la possibilité de modifier ce membre...

Or, on peut estimer que, si tu as pris la peine de déclarer un membre comme étant privé et de créer un accesseur (et pourquoi pas un mutateur), c'est parce que tu as estimé préférable d' "encadrer" la manière dont les modifications apportées à ce membre seront effectuées...

Si tu donnes (par le retour d'une référence non constante) la possibilité de modifier le membre "depuis l'extérieur", tu brise l'encapsulation et tu perd le contrôle des modifications qui seront apportées

[hydrolyre]

Merci !