Discussion :

[Rafy]

Une référence, ne peut pas être invalide, contrairement aux pointeurs.
Ca c'est ce qu'on dit toujours à propos des références, c'est peut-être même dans la définition.
Elle est initialisée à la création et ainsi ne peut pas 'pointer' sur NULL comme un pointeur pourrait le faire.

Mais quand une référence 'pointe' sur un objet qui est détruit :
Nous avons deux cas possibles :
La référence était précédement valide.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <iostream>
int i = 2;
int& refi = i;    // refi est initialisée avec i
{
        int j = 7;    // Ici la porté de j est limité jusqu'a la fin des accolades...
        refi = j;
        std::cout << "Entre les accolades : refi = " << refi << std::endl;    // Affiche 7
}
// Ici refi est 'invalidée' car j n'existe plus
std::cout << "Juste après les accolades : refi = " << refi << std::endl;    // Affiche 2
// Mais comme les références c'est pas trop bête,
// en fait ça reprend la dernière référence valide, soit la référence sur i

La tout se passe bien car la référence à déjà eu une valeur valide, celle de i avant d'avoir une valeur 'invalide'.

La référence est initialisé avec un élément qui va devenir invalide.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <iostream>
class A
{
    public:
        int i;
};
A* pA = new A;
pA->i = 2;
int& refi = pA->i;
std::cout << "Avant la destruction : refi = " << refi << std::endl;
delete pA;
std::cout << "Après destruction : refi = " << refi << std::endl;

Dans ce cas la référence est valide à sa création, elle initialisée. Avant la destruction le premier cout nous dit que refi vaut 2, comme il faut.
Et le second nous donne également 2. Mais la référence n'est plus valide car pA->i n'existe plus car pA à été détruit...
Donc en fait refi 'pointe' sur un endroit de la mémoire qui était utilisé avant pour stocker la valeur de i, donc 'vaut' toujours 2, mais c'est comme un pointeur, qui pointait sur un objet que l'on vient de détruire....

Ma question :
Est il possible que quelqu'un me dise si je dis faut ou non.
Si oui ou est ma faute?

Si non n'est-il pas plus dangereux de se servir des réference dans le cadre des exemples ci-dessus ?
Il est possible de trouver d'autre cas similaires ou les références sont 'invalides'.

J'ai mis pointe, vaut et invalide car je ne sais pas si on peut parler des références avec le vocabulaire des pointeurs.

(compilation et tests réalisés avec VisualStudio 2005, pas de problème de compilation ni de lieur, pas d'avertissement même niveau 4)

[b Oo]

Salut,
tu es sûr que ton premier exemple produit le résultat que tu as dis ?
Je pense plutôt que les deux fois refi affiche 7.

En effet, tu peux considérer refi comme i lui-même (moi je le considère comme un pointeur constant sur i, mais ce n'est pas l'avis de tout le monde : http://c.developpez.com/faq/cpp/?pag...TION_reference).
Donc quand tu fais :

Code :

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

1
2
3
 
int j = 7;
refi = 7; // equivalent à i = 7

C'est i qui est modifié et non refi (qui pointe toujours sur i).

Pour le deuxième exemple, je pense que ton explication est la bonne (si on considère que refi est un pointeur constant sur pA), à moins que lorsque l'on détruit pa cela détruise aussi la référence (à voir).

b Oo

[JolyLoic]

Code :

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

1
2
3
4
5
6
#include <iostream>
int i = 2;
int& refi = i;    // refi est initialisée avec i
{
        int j = 7;    // Ici la porté de j est limité jusqu'a la fin des accolades...
        refi = j;

Ce code ne fait pas ce que tu crois... Il ne fait en rien de refi une référence à j. Il affectue juste à ce à quoi refi fait référence la valeur de j. Elle est équivalente à i=j;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include <iostream>
class A
{
    public:
        int i;
};
A* pA = new A;
pA->i = 2;
int& refi = pA->i;
std::cout << "Avant la destruction : refi = " << refi << std::endl;
delete pA;

Là, problème : Tu fais une chose qui est interdite en C++. La suite de ton programme est en droit de faire n'importe quoi.

Quand on dit qu'une référence est toujours valide, ça veut dire qu'il est impossible d'avoir une référence invalide, car toutes les temtatives pour faire conduisent à des comportement indéfinis auparavant.
Et donc, il ne sert à rien (et il n'est pas possible) de vérifier la validité d'une référence, car :
- Soit le programme est valide, et la référence le sera
- Soit le programme n'est pas valide, et de toute façon, on ne peut rien dire sur son comportement.

[Rafy]

Je crois voir ce que tu veut dire pour l'exemple 1;
Pour ce qui est du second exemple je ne vois pas à quelle ligne j'ai fais un truc interdit...

[Pragmateek]

Il affectue juste à ce à quoi refi fait référence la valeur de j. Elle est équivalente à i=j;

En effet une référence, comme un pointeur, est une sorte "d'intermédiaire" vers un autre objet.

Mais alors comment faire pour réafecter une référence, faire en sorte qu'elle se réfère à un autre objet?

[Swoög]

Je crois voir ce que tu veut dire pour l'exemple 1;
Pour ce qui est du second exemple je ne vois pas à quelle ligne j'ai fais un truc interdit...

en fait, tu fais déjà un truc pas bien : l'encapsulation n'est pas respectée dans ta classe, il est très dangeureux de donner un accès par référence à un donnée membre d'une classe. On s'en accomode dans certains cas (opérateurs *, -> ou encore []) mais c'est jamais le top ! Il faut garder à l'esprit que c'est une faille dans la classe puisqu'on peut logiquement faire n'importe quoi avec cette variable)

ensuite, ton code revient à dire :

Code :

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

1
2
3
4
int* a = new int;
int *b = a;
delete a;
*b = 5;

et là ? il se passe quoi ?

ça plante, normal, et bien c'est exactement ce que fait ton code...

Le problème des pointeurs fantomes est impossible à éviter en C++ à moins d'utiliser une classe de smart pointeur qui ne donne aucun accès en référence à la variable, et c'est très dur à faire pour ne pas dire quasi-impossible !

Toujours est-il comme l'a dit JoyLoic que les références sont, dans tous les cas plus sécurisée que les pointeurs, même si bien sûr elles ne sont pas parfaites...

[JolyLoic]

Mais alors comment faire pour réafecter une référence, faire en sorte qu'elle se réfère à un autre objet?

Ce n'est pas possible.

[Rafy]

Ouais c'est bien ce que je me disais à propos du 'reréférencement'...
C'est pas possible. Donc en fait les références et les pointeurs ont chaqun leurs avantages et leurs inconvénients.... Je trouve quand même que c'est beaucoup plus vicieux que les pointeurs...
J'utilise la règle suivante pour les passages par arguments :
-> Utilisation d'une référence constante pour passer un objet par argument à une méthode ou fonction si elle ne modifie pas l'objet.

Code :

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

1
2
 
void Fonction1(const Objet& ObjetQuiNeSeraPasModifié)

-> Utilisation d'un pointeur (intelligent ou non) pour un passage d'objet, par argument, qui sera ou sera suceptible d'être modifié.

Code :

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

1
2
 
void Fonction2(Objet* ObjetQuiSeraPeutEtreModifie)

Mais le but de mon post était d'éclaircir certains points sur les références....
Donc les références c'est bien mais MEF!!!
Merci à tous pour vos réponses.

[Pragmateek]

Ce n'est pas possible.

Pas cool!

Sinon comment se "débarrasser" d'une référence quand elle ne sert plus?
Ca aussi c'est impossible?

[Laurent Gomila]

Tu la définis dans un bloc d'accolade plus restreint.

[Aurelien.Regat-Barrel]

En effet une référence, comme un pointeur, est une sorte "d'intermédiaire" vers un autre objet.

Mais alors comment faire pour réafecter une référence, faire en sorte qu'elle se réfère à un autre objet?

c'est ce qui distingue une référence d'un pointeur.

[loufoque]

-> Utilisation d'un pointeur (intelligent ou non) pour un passage d'objet, par argument, qui sera ou sera suceptible d'être modifié.

Code :

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

1
2
 
void Fonction2(Objet* ObjetQuiSeraPeutEtreModifie)

Quel est l'intérêt ?
Il suffit de passer l'objet par référence.

[Swoög]

Quel est l'intérêt ?
Il suffit de passer l'objet par référence.

+1
les pointeurs ne devraient être utilisés pour des arguments de fonctions que pour faire des types "NULLABLE" (pouvoir choisir de ne pas faire passer de valeur) et pour différencier trois comportements (un sans le paramètre, un avec le paramètre NULL, un avec le paramètre valué)...

[Rafy]

Une personne qui utilise une fonction que j'ai codé, voit ainsi si ce qu'elle passe en argument est suceptible d'être modifié....
Si c'est un pointeur ça peut être modifié, si c'est une référence constante ça ne le sera pas....
Et en plus c'est un conseil de Byarne Strostroup dans son Bouquin

[Swoög]

Si c'est un pointeur ça peut être modifié, si c'est une référence constante ça ne le sera pas....

Si c'est une référence ça peut être modifié, si c'est une référence constante ça ne le sera pas....

[Rafy]

Je suis d'accord qu'avec une référence non constante sur un objet on peut le modifier....
Mais les références ne permettent pas de faire certaines choses que les pointeurs permettent de faire....
Un objet qui ne dispose pas d'opérateur de copie ni de constructeur de copie ne pourra être introduit dans une liste ou autre conteneur que par le biais de pointeur, les références sont d'aucunes utilités dans ce cas la...
si tu essaie de faire une std::list<Objet& >, ça ne va pas compiler.
si tu essaie de faire une std::list<Objet>, et que ton objet n'a pas d'opérateur de copie ni de constructeur de copie, tu ne pourra jamais en insérer dans ta liste....
Et en plus tu ne pourra pas modifier les objets que tu as insérés sans les retirer et les remettre ensuite.....
Mais une std::list<Objet* > ou même une std::list<boost::shared_ptr<Objet> > permettra tout cela...

[Rafy]

Ce que je voulais dire avec mes références constantes et mes pointeurs pour passage d'argument, c'est une 'règle' de programmation, pas un truc formel qui est dans la norme...
Mais comme c'est un conseil de mec qui touche quand même pas mal en C++, je pense que ça peut valoir le coup de suivre leurs explications :
Références constantes -> argument qui ne sera pas modifié.
Pointeur -> argument qui est suceptible d'être modifié.

[loufoque]

Un objet qui ne dispose pas d'opérateur de copie ni de constructeur de copie ne pourra être introduit dans une liste ou autre conteneur que par le biais de pointeur, les références sont d'aucunes utilités dans ce cas la...

Quel rapport avec l'histoire de passage par référence évoqué précedemment ?

Et en plus tu ne pourra pas modifier les objets que tu as insérés sans les retirer et les remettre ensuite.....

C'est quoi cette nouvelle fantaisie ?

[JolyLoic]

Si c'est une référence ça peut être modifié, si c'est une référence constante ça ne le sera pas....

Le problème ennoncé par certains, c'est que si tu vois f(x), tu dois regarder la définition de f pour savoir si x est passé par valeur, par référence constante ou par référence non constante. Quand tu vois f(&x), tu sais que tu passes un pointeur.

Je trouve cet argument peu convainquant. Pour deux raisons : Déjà, l'on doit alors documenter qui est sensé allouer/désallouer le pointeur, ce qui demande plus d'infos que le prototype, et il peut conduire à du code moyen. Je préfère

Code :

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

1
2
3
4
5
void f(int &result)
{
  result = g();
  result = (2+result) * result;
}

à

Code :

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

1
2
3
4
5
6
7
8
void f(int *result)
{
  if (result != NULL)
  {
    *result = g();
    *result = (2+*result) * * result;
  }
}

[TanEk]

Le problème ennoncé par certains, c'est que si tu vois f(x), tu dois regarder la définition de f pour savoir si x est passé par valeur, par référence constante ou par référence non constante. Quand tu vois f(&x), tu sais que tu passes un pointeur.

Et si x est un argument pointeur on écrit quand même f(x) à moins qu'on ait des règles de nommage style p_x pour dire "pointeur x". Moi personnellement je suis plutôt : ou tout est pointeur ou tout est référence (si on mélange les deux on ne sait plus lequel est un pointeur et lequel est une référence).