Discussion :

[deubelte]

Bonjour
J'ai une question concernant le code suivant:

Code :

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

1
2
3
4
5
6
void main(){
   char const rc3='e';  char x('k');char fr('r');
    char &rc2=x; 
 
 
}

Je ne connaissais pas la facon de déclarer: x('k'), mais elle semble totalement équivalente à cette facon de déclarer:
x='k';

Ensuite, on a : char &rc2=x;

Mais surtout : quelle est la différence entre char &rc2=x; et char rc2=x;
rc2 est dans les deux cas, non pas un pointeur sur char mais un char. Mais zalors, a quoi sert &?

Merci

[camboui]

Bonjour
J'ai une question concernant le code suivant:

Code :

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

1
2
3
4
5
6
void main(){
   char const rc3='e';  char x('k');char fr('r');
    char &rc2=x; 
 
 
}

Je ne connaissais pas la facon de déclarer: x('k'), mais elle semble totalement équivalente à cette facon de déclarer:
x='k';

Oui.

Ensuite, on a : char &rc2=x;

Mais surtout : quelle est la différence entre char &rc2=x; et char rc2=x;
rc2 est dans les deux cas, non pas un pointeur sur char mais un char. Mais zalors, a quoi sert &?

Merci

La nuance est fondamentale. Pas de C++ sans comprendre.
Avec le "&" rc2 est une référence sur x, c'est à dire que c'est la "même variable", alors que sans le "&" rc2 est une autre variable qui va prendre la valeur de x lors de son initialisation.

En pratique, pour le compilateur une référence est un pointeur.

[deubelte]

Merci, mais un pointeur n'est pas du tout une référence, c'est une adresse?

[jblecanard]

Exactement ! Un pointeur est une variable qui va contenir une adresse vers une plage mémoire. La traduction en langage machine est naturelle.

Une référence est une notion qui n'a lieu que dans le code C++ et se retrouve traduite sous forme de pointeur à la compilation.

Une référence telle que tu l'utilises dans ton exemple n'est pas vraiment utile. L'utilité d'une référence se situe dans les signatures de méthodes. Exemple (avec des fonctions libres pour alléger) :

Code :

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

1
2
3
4
5
6
7
8
9
void f(int x){
   x++:
}
 
void main(){
   int a = 0;
   f(a);
   std::cout << a << std::endl;
}

Ce code va afficher "0" en sortie, a n'est pas modifiée.

Code :

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

1
2
3
4
5
6
7
8
9
void f(int& x){
   x++:
}
 
void main(){
   int a = 0;
   f(a);
   std::cout << a << std::endl;
}

Ce code va afficher "1" en sortie, a est modifiée car la fonction récupère une référence et pas une copie de la variable.

Avantages :
- Le code appelant (dans main) n'est pas modifié pour rendre a modifiable par la fonction.
- C'est un pointeur qui est passé (pas de copie de l'objet en mémoire, bien pour les gros objets).

[deubelte]

Ok, l'opération & revient à créer une nouvelle variable à partir de la première, mais ayant la même adresse.*
mathématiquement, peut on dire que & est une relation d'équivalence,

[3DArchi]

Ok, l'opération & revient à créer une nouvelle variable à partir de la première, mais ayant la même adresse.*
mathématiquement, peut on dire que & est une relation d'équivalence,

Ce n'est pas une opération, ce n'est pas une équivalence. C'est plutôt un synonyme. Ça ressemble plus au typedef pour les types.

[jblecanard]

Attention tout de même deubelte, la référence présente des comportements différents dans certains cas. Par exemple, quand la référence est détruite et dépilée à la fin du bloc dans lequel elle est déclarée, l'objet référencé ne l'est pas.

D'une manière générale, la référence est souvent perturbante pour les débutants en C++ . Bon courage pour la suite.

[Goten]

Le point le plus important reste qu'une référence ne peut pas être NULL amha..

[camboui]

Le point le plus important reste qu'une référence ne peut pas être NULL amha..

Affirmation dangeureuse.

Code :

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

1
2
int *pi=NULL;
int & ri=*pi;

Mais bon, en principe ça ne devrait pas arriver...

[JolyLoic]

Affirmation dangeureuse.

Code :

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

1
2
int *pi=NULL;
int & ri=*pi;

Mais bon, en principe ça ne devrait pas arriver...

Quand tu fais *pi, tu provoques un comportement indéfini. Le code est tout à fait en droit de crasher à cet endroit, par exemple (et j'ai entendu parler d'architectures où il le fait). Donc on ne peut pas avoir de référence NULL dans le cadre du langage.

[Goten]

Affirmation dangeureuse.

Code :

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

1
2
int *pi=NULL;
int & ri=*pi;

Mais bon, en principe ça ne devrait pas arriver...

Déférencer un pointeur NULL c'est une UB, donc non c'est faux, et je réitére une référence ne peut pas être NULL .

edit : désolé j'avais pas vu ta réponse Loic..

[deubelte]

Toujours en ce qui concerne les &, si on prend le code suivant:

Code :

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

1
2
3
4
5
6
7
8
 
int f(int o){
return o=o+1
}
int main(){
int u=0;
u=f(1);
}

ok, aucun pb, on aura 2

Ensuite, si on prend le code suivant:

Code :

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

1
2
3
4
5
6
7
8
 
int& f(int o){
return o=o+1
}
int main(){
int u=0;
u=f(1);
}

la fonction renvoie une référence (de quoi d'ailleurs?) il semble que la variable dont on prend la référence soit détruite. Mais il y a bien des cas où on prend la référence de l'objet sortant: comme ici par exemple:

Code :

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

1
2
 
float& operator [] (int a)

[JolyLoic]

Ce code est invalide. Il retourne une référence à une variable locale, qui a été détruite à la sortie de la fonction. Le code comme l'opérateur [] retourne une référence non pas sur une variable locale à la fonction, mais généralement sur une donnée membre de la classe à laquelle l'opérateur est associé. Donc tand que l'objet vit, la référence est valide.

[deubelte]

Déférencer un pointeur NULL c'est une UB, donc non c'est faux, et je réitére une référence ne peut pas être NULL

Et pourquoi tu ne peux pas pointer sur NULL?
D'ailleurs, quand on fait:
int *o=NULL;

o n'est pas un pointeur qui pointe sur 0, mais un pointeur nul (?)

[jblecanard]

Un pointeur NULL est un pointeur qui contient l'adresse 0. Tu peux bien sûr promener un pointeur NULL, mais tu ne peux pas le déréférencer.

[camboui]

On joue sur les mots pouvoir et devoir.

Et j'insiste, comme deubelte, une référence peut être nulle, mais elle ne devrait pas l'être si le programmeur fait bien les choses.

Il suffit d'imaginer une fonction qui renvoit un pointeur, ce pointeur étant assigné à une référence sans vérification préalable.

Code :

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

1
2
3
4
5
object *foo();
 
object & ro=*foo();
...
//risque de crash dès la première utilisation de ro

Correction du code:

Code :

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

1
2
3
4
5
6
7
8
9
object *foo();
 
object *po=foo();
if (po)
{
 object & ro=*po;
 ...
 //on peut utiliser ro sans risque
}

J'ai déjà rencontré des cas de crash à cause de références nulles. Par exemple lorsqu'on utilise différentes bibliothèques, certaines étant "C like" et utilisant les pointeurs, d'autres étant C++ like et utilisant plutôt les références. Une interface faite à la va-vite entre les bibliothèques peut amener à bien des désagréments, des références nulles est étant un.

[jblecanard]

Moi je suis d'accord avec Goten, une référence ne peut pas être nulle parce que le déréférencement du pointeur NULL au moment de l'affectation de la référence va planter avant, et la référence NULL n'existera donc pas. Donc oui, ça fait du code qui plante, mais quand on a la main sur une référence dans du code, on peut être sûr qu'elle n'est pas NULL.

Edit : je viens de tester sur du code, au temps pour moi, on peut bien avoir une référence à NULL. Camboui a raison.

[camboui]

Justement non, c'est là que tu te trompes. C'est lors de l'utilisation de la référence que ça va planter, pas au moment de l'assignation de la référence par le déréférencement du pointeur.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
void foo(int const & ri)
{
std::cout << ri << std::endl;// c'est seulement ici que ça plante
}
 
int main()
{
int *pi=0;
foo(*pi);//pas de plantage ici
return 0;
}

Plantage dans la fonction, pas lors de son appel.
Fais le test, tu verras.

EDIT: bon, et bien voilà

[JolyLoic]

Déréférence un pointeur nul est un comportement indéfini. Là est le problème. A partir du moment ou tu as fait ça, rien n'est garanti dans la suite du programme.

There shall be no references to references, no arrays of references, and no pointers to references. The declaration of a reference shall contain an initializer (8.5.3) except when the declaration contains an explicit extern specifier (7.1.1), is a class member (9.2) declaration within a class declaration, or is the declaration of a parameter or a return type (8.3.5); see 3.1. A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a welldefined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bitfield.]

Il se peut qu'avec ton compilateur, dans ton environnement d'exécution, avec tes options de compilation, ce comportement indéfini se traduise par "rien ne se passe, mais ça plante plus tard".

Dans d'autres conditions, ce plantage peut intervenir bien plus tôt.

Remarque : ce n'est pas à initialisation de la référence non plus qu'est le problème, mais vraiment au déréférencement de NULL lui même.

[jblecanard]

Remarque : ce n'est pas à initialisation de la référence non plus qu'est le problème, mais vraiment au déréférencement de NULL lui même.

Tout à fait d'accord, mais du fait de la nature d'une référence, il aurait été envisageable que le compilo déréférence le pointeur avant d'affecter la référence, ne serais-ce que dans le but de faire planter le code à cet endroit là et pas plus tard. Ce serait même logique sur le plan sémantique, la syntaxe (*pointeur) étant censée le déréférencer.

Dans la pratique, on voit que ce n'est pas le cas.