Discussion :

[sphere369]

Bonjour,

Je suis entrain de faire un exercice dont j'ai du mal a comprendre la reponse (il me semble même qu'il y ai erreur) :

Questions :Vrai ou faux ? Expliquez pourquoi

a) Si (x == y) alors (&x == &y)
b) Si (x == y) alors (*x == *y)

Réponses :

a) Vrai : &x == x et &y == y car &x et &y sont respectivement synonymes de x et de y, donc si (x == y) ils possèdent alors tous la même valeur.

b) Faux : des objets différents peuvent avoir la meme valeur, mais differents objets ont des adresses différentes.

Normalement, &x == &y ne veut il pas dire que l'adresse de x est egale a l'adresse de y. Et un referencement est du type : int& z = a, (z etant alors un synonyme de x).Je ne comprends donc pas clairement les reponses données ci-dessus.

[ram-0000]

J'ai l'impression qu'il y a plusieurs interprétations suivant la lecture que l'on fait

• Si (x == y) alors adresse de x == adresse de y je dirais que ce n'est pas forcément vrai
  
• Si (x == y) et que x et y sont des pointeurs alors l'objet pointé par x est le même que l'objet pointé par y vrai

[koala01]

Salut,

A vrai dire, l'énoncé n'est pas clair du tout, parce que & peut tout aussi bien correspondre à la déclaration d'une référence (quand il est utilisé sous la forme de type & var = truc) qu'à la prise de l'adresse de la variable (lorsqu'il est utilisé sous la forme de type * ptr= &truc)...

De même, * peut tout aussi bien correspondre à la déclaration d'un pointeur (lorsqu'il est utilisé sous la forme de type *ptr) qu'au fait d'accéder à l'élément pointé par le pointeur (lorsqu'il est utilisé sous la forme de type var= *ptr)...

Mais peut être cette question est-elle à replacer dans le contexte de l'explication de la différence entre les références et les pointeurs

Dans ce cas, l'énoncé devrait être compris sous la forme suivante:
Avec deux variables déclarée sous la forme de

Code :

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

1
2
type x;
type y;

si x==y la situation suivante est-elle juste

Code :

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

1
2
3
type & refx=x;
type & refy=y;
refx==refy

et celle-ci

Code :

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

1
2
3
type *ptrx=&x;
type *ptry=&y;
ptrx==ptry

d'après les explications que ton livre fournit, il semblerait que ce soit ce type d'énoncer que l'auteur voulait faire passer

Et la réponse tient donc en:
refx et refy sont des références (des alias) des variables x et y. Si x==y, refx est donc égal à refy parce que refx est assimilé à x et refy est assimilé à y

Par contre, ptrx et ptry sont des pointeurs (donc des variables représentant l'adresse à laquelle se trouve une donnée particulière) x et y étant des objets différents, il se trouvent, fatalement, à des adresses mémoire différentes, même si leur valeur est identique.

l'adresse pointée par ptrx n'est donc pas la même que l'adresse pointée par ptry

[Médinoc]

Je ne vois aucune ambiguïté dans l'énoncé, par contre les deux réponses sont incorrectes:

1. Si (x == y) alors (&x == &y)
   
   • FAUX: Deux objets distincts peuvent être égaux, mais n'auront pas la même adresse.
2. Si (x == y) alors (*x == *y)
   
   • VRAI: Si deux pointeurs sont égaux, alors ils pointent sur la même chose: Donc, leur déréférencement retournera la même valeur.

[koala01]

Je ne vois aucune ambiguïté dans l'énoncé, par contre les deux réponses sont incorrectes:

1. Si (x == y) alors (&x == &y)
   
   • FAUX: Deux objets distincts peuvent être égaux, mais n'auront pas la même adresse.
2. Si (x == y) alors (*x == *y)
   
   • VRAI: Si deux pointeurs sont égaux, alors ils pointent sur la même chose: Donc, leur déréférencement retournera la même valeur.

Mais c'est fondamentalement à l'opposé des réponses présentées comme solution...

Alors, de deux choses l'une:
Soit l'auteur (ou le traducteur) avait bu lorsqu'il a écrit son texte (et inversé l'ordre de ses réponses), soit il a mal exprimé sa question en fonction de la réponse à laquelle il voulait que le lecteur arrive...

Tu pars sur la première hypothèse et moi sur la deuxième

Mais les deux sont aussi mauvais signe l'une que l'autre: dans les deux cas, on en vient à douter de la qualité de l'ouvrage (ou de la traduction)

[sphere369]

Mais les deux sont aussi mauvais signe l'une que l'autre: dans les deux cas, on en vient à douter de la qualité de l'ouvrage (ou de la traduction)

C'est claire. Je viens de revoir la version originale (en anglais) et ce sont les mêmes réponses.

En ce qui me concerne, j'adopte tout simplement la version de Koala01.

Merci a tous pour votre aide.

[3DArchi]

Je ne vois aucune ambiguïté dans l'énoncé, par contre les deux réponses sont incorrectes:

1. Si (x == y) alors (&x == &y)
   
   • FAUX: Deux objets distincts peuvent être égaux, mais n'auront pas la même adresse.
2. Si (x == y) alors (*x == *y)
   
   • VRAI: Si deux pointeurs sont égaux, alors ils pointent sur la même chose: Donc, leur déréférencement retournera la même valeur.

Je comprend exactement comme ça. Et donc c'est cette réponse que j'aurais fournie. A une nuance près, si y est une référence sur x, alors &y==&x même s'il s'agit de 2 variables distinctes. Cependant, d'un point de vue logique le prédicat Si (x == y) alors (&x == &y) reste faux.

[sphere369]

Nous sommes bien d'accord: l'énoncé de cet exercice n'est pas terrible. Mais bon si j'arrive a faire voir qu'il y a quelque chose qui cloche alors c'est déjà positif.

Encore merci a tous,

Sphere369

[koala01]

Nous sommes bien d'accord: l'énoncé de cet exercice n'est pas terrible

Disons le clairement: il est tout à fait incohérent avec la solution présentée...

Juste pour info, pourrais tu nous dire d'où est tiré cet exercice

[sphere369]

Disons le clairement: il est tout à fait incohérent avec la solution présentée...

En effet...peut etre que je m'étais mal fait comprendre.


Concernant le livre dont est extrait l'exercice, c'est mon fameux bouquin "programming in c++" de J. Hubbard, exercice 7.6 (ci-joint un copié écran de la page (en .acsm)).

A bientôt,

Sphere369

[Pragmateek]

Pour la deuxième question, tout dépend de ce qui est considéré comme un "pointeur" : si c'est tout type pouvant être déréférencé via l'opérateur "*" alors tout dépend de la logique métier des entités.

Une illustration simplifiée :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <cstdlib>
#include <iostream>
 
using namespace std;
 
class Fake
{
	public: void* operator*()
	{
		return this;
	}
 
	public: bool operator==(Fake const &)
	{
		return true;
	}
};
 
int main(void)
{
	Fake x, y;
 
	cout << (x == y) << endl;
	cout << (*x == *y) << endl;
 
	return EXIT_SUCCESS;
}

Résultat :

Code :

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

1
2
1
0

[coyotte507]

Moi j'ai l'impression qu'il s'est un peu emmêlé:

Code :

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

1
2
a) Si (x == y) alors (x& == y&) // en considérant le '&' comme une référence vers x/y
b) Si (x == y) alors (x* == y*) // en considérant le '*' comme un pointeur vers x/y

Et alors les réponses données seraient correctes.

[Alp]

Je ne vois aucune ambiguïté dans l'énoncé, par contre les deux réponses sont incorrectes:

1. Si (x == y) alors (&x == &y)
   
   • FAUX: Deux objets distincts peuvent être égaux, mais n'auront pas la même adresse.
2. Si (x == y) alors (*x == *y)
   
   • VRAI: Si deux pointeurs sont égaux, alors ils pointent sur la même chose: Donc, leur déréférencement retournera la même valeur.

Gros +1.

Précisons :
1) Pour toutes variables x et y (pointeurs ou pas), on peut en récupérer l'adresse.
Ok.
Mais si on a

Code :

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

int a = 1, b = 1;

Alors &a n'a aucune raison de valoir &b. Dans ce cas précis, c'est même faux, à coup sûr. Donc, d'une manière générale, (x == y) => (&x == &y) est ABSURDE ET FAUX.
C'est même l'une des premières choses que l'on montre quand on explique les histoires de valeurs, pointeurs, adresses...

2) Si x et y sont des pointeurs bruts, c'est vrai. En effet, si deux pointeurs pointent vers la même adresse, forcément, le contenu à cette adresse est le même... qu'on y accède par x ou par y.
Si x et y sont des objets plus complexes qui surchargent l'opérateur * (mais dans le cadre d'un déréférencement ou quoi, pas d'une multiplication évidemment... c'est à dire pas d'arguments à l'opérateur * --- je pense aux itérateurs de la STL, par exemple) alors aucune garantie, loin de là. Cela repose sur les implémentations de l'opérateur == et de l'opérateur * pour ces types là.
Donc l'énoncé est "vrai vite fait" mais très très baclé surtout. L'auteur me semble surtout être un parmi tant qui a écrit un bouquin pour la gloire ou je ne sais quoi, mais pas pour le savoir. Ca me fait penser à un auteur français qu'on adore tous pour ses bouquins C++, et qui écrit aussi sur le Java, mais bizarrement mieux