Différence entre passage par référence et passage par adresse

Bonjour,

je sais que le titre est impropre, car le passage par adresse n'est qu'un passage par valeur avec un pointeur.

Mais je voulais savoir la différence et l'intérêt d'utiliser l'un plutôt que l'autre.

Ces deux fonctions sont-elles donc totalement équivalentes et produisent-elles les mêmes instructions ?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

//1
void transformeEn6(int &a)
{
    a = 6;
}

//que j'appelle comme ça
int var;
transformeEn6(var); //var = 6

//2
void tranformeEn6(int *a)
{
    *a = 6;
}

//que j'appelle comme ça
int var;
transformeEn6(&var);

Salut !

De ce qu'il me semble, par référence tu est sûr que la valeur n'est pas null (plus en C++17?) Tu as donc moins de conditions à vérifier avant.

En plus de la réponse correcte de mon VDD,

Allen Holub, donne deux règles (120 et 121) importantes concernant ta question,

• 120 Reference arguments should always be const
• 121 Never use references as outputs, use pointers

Merci de déjà me répondre !

Mais donc, à part ça, les mécanismes bas-niveau sont exactement les mêmes ?

Et sinon, je ne comprends pas la règle 121.

Merci !

Allen Holub, donne deux règles (120 et 121) importantes concernant ta question,

Tres bof comme regles, cela semble plus a du C++ old school.

Les recommandations actuelles sont plutot vers eviter l'utilisation des pointeurs nus. Cf https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-conventional

Mais donc, à part ça, les mécanismes bas-niveau sont exactement les mêmes ? Ces deux fonctions sont-elles donc totalement équivalentes et produisent-elles les mêmes instructions ?

En interne, le compilateur utilisera la meme chose (une adresse dans la pile). Donc pas de difference de performance.

Mais…

Mais je voulais savoir la différence et l'intérêt d'utiliser l'un plutôt que l'autre.

Tu ne sais pas comment tes fonctions seront utilisees. (oui, tu sais comment tes fonctions sont appellees quand tu travailles tout seul sur un hello world, mais pas quand tu bosses dans une equipe sur un programme de 100 000 lignes de code).

Un pointeur PEUT etre invalide, donc il doit TOUJOURS etre verifier avant utilisation, avec un assert ou un if. Ton code avec pointeur n'est donc pas correct.

La version avec reference doit donc etre privilegiee. (En fait, tu peux meme oublier pendant quelques temps les pointeurs nus si tu debutes).

EDIT:

la valeur n'est pas null (plus en C++17?)

Pas vu de changement de ce cote en C++17 ou dans les drafts.

Ouf, alors si je dois apprendre les nouveaux standards, en plus… Déjà que je ne connais quasi rien du 11, que le 14 est sorti, et si encore le 17 va « bientôt » arriver…

Merci pour les explications !

Concentre-toi sur C++20

Plus sérieusement, intéresse-toi au moins à C++11 qui simplifie énormément de chose et permet d'écrire un code plus juste. La sémantique de déplacement est l'une des nouveauté qui amènent le plus de changement.

La norme de 2014 est une évolution plutôt mineure et naturelle avec peu de changements:

• pas de nouveau mot clef, seulement plus de possibilité et moins de contraintes.
• peu d'ajout dans la bibliothèque standard.
• pas ou peu de nouvelle syntaxe.

(la version 6 de gcc est en 14 par défaut)

Après ça, apprendre le 17 sera très rapide.

D'accord, on verra ça quand j'aurai du temps (à perdre, hum, mais que fais-je à programmer, dans ce cas )

• pas de nouveau mot clef, seulement plus de possibilité et moins de contraintes.

auto n'est pas sorti en C++14 ?

auto n'est pas sorti en C++14 ?

Non, C++11. (Et en fait, "auto" est déjà un mot clé en C++98/03, donc techniquement, ce n'est même pas un nouveau mot clé du C++11 )

Ouf, alors si je dois apprendre les nouveaux standards, en plus…

1. pas besoin de "en plus", apprends un standard récent.
2. A part la question de Necros211, il n'y a rien de spécifique au C++11/14/17 dans cette discussion, c'est valide pour les anciennes normes aussi.

D'accord j'avais cru lire que les références aurais pus devenir null en C++17, merci pour cette confirmation !

Elles peuvent devenir null. En bidouillant un peu.

1
2

int* i{};
int& j{*i}; //nullptr

Tu crées un undefined behavior, donc sémantiquement ce n'est pas nullptr que vaut "j" mais n'importe quoi puisque ton programme n'a pas de sémantique.

Pourmoi la différence essentielle c'est que la référence ne peut jamais être nulle, elle pointe toujours vers un objet valide. A mon avis c'est la seule chose importante à retenir ici.

Oui on peut bidouiller pour la rendre nulle, mais il faut vraiment faire exprès, et à moins de savoir ce qu'on fait, on ne fait jamais ça.

L'autre message important qu'on transmet à l'utilisateur de la fonction quand on doit lui passer une référence plutôt qu'un pointeur, c'est « je ne m'occupe pas de la mémoire; tu dois me donner un objet valide, et il sera encore valide après mon retour ».

Non. On peut faire n'importe quoi depuis très longtemps. Mais il faut le faire exprès.

En revanche, this gagne la garantie de non nullité.

En revanche, this gagne la garantie de non nullité.

Ah ? IL y a des cas où this peut être nul ? Ca par contre ça me paraît particulièrement étrange…

Il a des gens qui vérifie si this = nul pour faire de la récursivité avec des structures imbriquées:

1
2
3
4
5
6
7
8

struct S {
  S * next;
  void foo() {
    if (this == nullptr) return ;
    ...
    p->next();
  }
};

Alors que déplacer la condition sur p fait tout aussi bien l'affaire.

Cela vient du fait que gcc évalue this comme un pointeur potentiellement nul. À partir de la version 6, il y a un avertissement pour les tests du genre this == nullptr. La 6.1 considère this comme toujours différent de nullptr et propose une option pour revenir au comportement précédent.

Clang considère this comme non-nul et se justifie comme suit:

warning: 'this' pointer cannot be null in well-defined C++ code; comparison may be assumed to always evaluate to true [-Wtautological-undefined-compare]

Pas plus mal que cette garantie arrive en 17.

Mince. Vous me mettez un doute. Je ne sais plus si c'est une supposition qui arrive au niveau de gcc ou une garantie au niveau du langage.

Intuitivement, j'aurai dit que de base c'est invalide sémantiquement (mais ce serait pas le premier truc stupide dans la norme C++). Appeler une fonction membre, quelle qu'elle soit sur un this qui vaut nullptr, c'est équivalent à écrire :

1

static_cast<Foo*>(nullptr)->bar();

Foncièrement, c'est un déréférencement de la valeur nullptr. Même si on n'y fait pas d'accès. Surtout que ça ne peut fonctionner que si la fonction est non-virtuelle et qu'elle n'accède à rien de l'objet pointé avant de terminer.