Bonjour,
J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on
voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL :
void fct( Toto* t) // t peut être NULL, fct doit vérifier
void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ;
int main()
{
Toto t1;
Toto *t0 = 0;
Toto& t = t1; // ok tout va bien
t = *t0; // ca ne plante pas a l'execution !
// si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à
l'affectation !
}
Donc je peux passer une référence invalide (NULL) à une fonction !
Ou bien mon raisonnement est faux et on a aucune garantie sur les references
?
(testé avec gcc 2.95)
Bonjour, J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL : void fct( Toto* t) // t peut être NULL, fct doit vérifier void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ; int main() { Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution ! // si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à l'affectation ! }
Donc je peux passer une référence invalide (NULL) à une fonction ! Ou bien mon raisonnement est faux et on a aucune garantie sur les references ?
raisonnement faux (probablement sur la semantique de t = *t0).
a+, ld.
Amerio wrote:
Bonjour,
J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on
voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL :
void fct( Toto* t) // t peut être NULL, fct doit vérifier
void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ;
int main()
{
Toto t1;
Toto *t0 = 0;
Toto& t = t1; // ok tout va bien
t = *t0; // ca ne plante pas a l'execution !
// si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à
l'affectation !
}
Donc je peux passer une référence invalide (NULL) à une fonction !
Ou bien mon raisonnement est faux et on a aucune garantie sur les references
?
raisonnement faux (probablement sur la semantique de t = *t0).
Bonjour, J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL : void fct( Toto* t) // t peut être NULL, fct doit vérifier void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ; int main() { Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution ! // si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à l'affectation ! }
Donc je peux passer une référence invalide (NULL) à une fonction ! Ou bien mon raisonnement est faux et on a aucune garantie sur les references ?
raisonnement faux (probablement sur la semantique de t = *t0).
a+, ld.
Marc Boyer
In article <41e27eb4$0$19589$, Amerio wrote:
Bonjour, J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL : void fct( Toto* t) // t peut être NULL, fct doit vérifier void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ; int main() { Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution !
Sauf qu'à partir du moment ou tu as écrit *t0, tu as provoqué un Undefined behavior, donc ce qui se passe désormais peut-être n'importe quoi.
Tu pourrais aussi écrire memset(&t, 0, sizeof(Toto&) ); tu aurais surement le même ganre de comportement.
// si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à l'affectation ! }
Donc je peux passer une référence invalide (NULL) à une fonction ! Ou bien mon raisonnement est faux et on a aucune garantie sur les references ? (testé avec gcc 2.95)
Ton raisonnement a un biais. C'est comme les gens qui démontrent 1=2 en faisant une division par 0.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <41e27eb4$0$19589$636a15ce@news.free.fr>, Amerio wrote:
Bonjour,
J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on
voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL :
void fct( Toto* t) // t peut être NULL, fct doit vérifier
void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ;
int main()
{
Toto t1;
Toto *t0 = 0;
Toto& t = t1; // ok tout va bien
t = *t0; // ca ne plante pas a l'execution !
Sauf qu'à partir du moment ou tu as écrit *t0, tu as provoqué
un Undefined behavior, donc ce qui se passe désormais peut-être
n'importe quoi.
Tu pourrais aussi écrire
memset(&t, 0, sizeof(Toto&) );
tu aurais surement le même ganre de comportement.
// si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à
l'affectation !
}
Donc je peux passer une référence invalide (NULL) à une fonction !
Ou bien mon raisonnement est faux et on a aucune garantie sur les references
?
(testé avec gcc 2.95)
Ton raisonnement a un biais. C'est comme les gens qui démontrent 1=2
en faisant une division par 0.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Bonjour, J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL : void fct( Toto* t) // t peut être NULL, fct doit vérifier void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ; int main() { Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution !
Sauf qu'à partir du moment ou tu as écrit *t0, tu as provoqué un Undefined behavior, donc ce qui se passe désormais peut-être n'importe quoi.
Tu pourrais aussi écrire memset(&t, 0, sizeof(Toto&) ); tu aurais surement le même ganre de comportement.
// si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à l'affectation ! }
Donc je peux passer une référence invalide (NULL) à une fonction ! Ou bien mon raisonnement est faux et on a aucune garantie sur les references ? (testé avec gcc 2.95)
Ton raisonnement a un biais. C'est comme les gens qui démontrent 1=2 en faisant une division par 0.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
xavier
Amerio a dis le 10/01/2005 14:09:
t = *t0; // ca ne plante pas a l'execution !
Attention, cette instruction est équivalent à : t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Il est toujours possible de créer une référence invalide, par exemple :
Toto & t = *(Toto *)0;
Mais il est impossible de manipuler une référence autrement qu'en la déreferençant. C'est ce point qui fait la force d'une référence par rapport à un pointeur. A partir du moment ou tu es sûr qu'une référence a été correctement construite (i.e. qu'elle est valide), tu peux être sûr que cette référence continuera d'être valide et qu'elle "pointera" vers le même espace mémoire pendant toute sa vie.
// exemple.cpp #include <iostream>
struct Toto {};
using namespace std;
int main() {
Toto t1; cout << &t1 << endl; Toto *t0 = 0; Toto &t = t1; cout << &t << endl; t = *t0; // [1] cout << &t << endl; Toto & t2 = *(Toto*)0; cout << &t2 << endl; return 0; } //eof
[1] Cette ligne ne provoque pas d'erreur à l'execution seulement parce que la structure Toto est vide, et donc son operateur de copie par défaut ne fait rien.
xavier
Amerio a dis le 10/01/2005 14:09:
t = *t0; // ca ne plante pas a l'execution !
Attention, cette instruction est équivalent à :
t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Il est toujours possible de créer une référence invalide, par exemple :
Toto & t = *(Toto *)0;
Mais il est impossible de manipuler une référence autrement qu'en la
déreferençant. C'est ce point qui fait la force d'une référence par
rapport à un pointeur. A partir du moment ou tu es sûr qu'une référence
a été correctement construite (i.e. qu'elle est valide), tu peux être
sûr que cette référence continuera d'être valide et qu'elle "pointera"
vers le même espace mémoire pendant toute sa vie.
// exemple.cpp
#include <iostream>
struct Toto {};
using namespace std;
int main() {
Toto t1;
cout << &t1 << endl;
Toto *t0 = 0;
Toto &t = t1;
cout << &t << endl;
t = *t0; // [1]
cout << &t << endl;
Toto & t2 = *(Toto*)0;
cout << &t2 << endl;
return 0;
}
//eof
[1] Cette ligne ne provoque pas d'erreur à l'execution seulement parce
que la structure Toto est vide, et donc son operateur de copie par
défaut ne fait rien.
Attention, cette instruction est équivalent à : t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Il est toujours possible de créer une référence invalide, par exemple :
Toto & t = *(Toto *)0;
Mais il est impossible de manipuler une référence autrement qu'en la déreferençant. C'est ce point qui fait la force d'une référence par rapport à un pointeur. A partir du moment ou tu es sûr qu'une référence a été correctement construite (i.e. qu'elle est valide), tu peux être sûr que cette référence continuera d'être valide et qu'elle "pointera" vers le même espace mémoire pendant toute sa vie.
// exemple.cpp #include <iostream>
struct Toto {};
using namespace std;
int main() {
Toto t1; cout << &t1 << endl; Toto *t0 = 0; Toto &t = t1; cout << &t << endl; t = *t0; // [1] cout << &t << endl; Toto & t2 = *(Toto*)0; cout << &t2 << endl; return 0; } //eof
[1] Cette ligne ne provoque pas d'erreur à l'execution seulement parce que la structure Toto est vide, et donc son operateur de copie par défaut ne fait rien.
xavier
Amerio
xavier wrote:
Amerio a dis le 10/01/2005 14:09:
t = *t0; // ca ne plante pas a l'execution !
Attention, cette instruction est équivalent à : t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Effectivement, je vois maintenant mon erreur ! Ca va tout de suite mieux quand on considere une reference comme un alias... (on ne devrait donc pas comparer l'usage de Toto& à celui de Toto*, mais à celui de Toto* const !) Merci !
xavier wrote:
Amerio a dis le 10/01/2005 14:09:
t = *t0; // ca ne plante pas a l'execution !
Attention, cette instruction est équivalent à :
t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Effectivement, je vois maintenant mon erreur !
Ca va tout de suite mieux quand on considere une reference comme un alias...
(on ne devrait donc pas comparer l'usage de Toto& à celui de Toto*, mais à
celui de Toto* const !)
Merci !
Attention, cette instruction est équivalent à : t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Effectivement, je vois maintenant mon erreur ! Ca va tout de suite mieux quand on considere une reference comme un alias... (on ne devrait donc pas comparer l'usage de Toto& à celui de Toto*, mais à celui de Toto* const !) Merci !
xavier
xavier a dis le 10/01/2005 14:53:
tu peux être sûr que cette référence continuera d'être valide et qu'elle "pointera" vers le même espace mémoire pendant toute sa vie.
Ceci voulant dire également que le code suivant va poser problème :
Toto * p = new Toto; Toto & t = *p; delete p; t.FaitQuelqueChose() ; // t "pointe" un espace mémoire libéré.
xavier
xavier a dis le 10/01/2005 14:53:
tu peux être sûr que cette référence continuera d'être valide et qu'elle "pointera"
vers le même espace mémoire pendant toute sa vie.
Ceci voulant dire également que le code suivant va poser problème :
Toto * p = new Toto;
Toto & t = *p;
delete p;
t.FaitQuelqueChose() ; // t "pointe" un espace mémoire libéré.
tu peux être sûr que cette référence continuera d'être valide et qu'elle "pointera" vers le même espace mémoire pendant toute sa vie.
Ceci voulant dire également que le code suivant va poser problème :
Toto * p = new Toto; Toto & t = *p; delete p; t.FaitQuelqueChose() ; // t "pointe" un espace mémoire libéré.
xavier
Marc Boyer
In article <41e28608$0$31781$, xavier wrote:
Amerio a dis le 10/01/2005 14:09:
t = *t0; // ca ne plante pas a l'execution !
Attention, cette instruction est équivalent à : t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Si, on peut modifier l'objet désigné par une référence. Ce qu'on ne doit pas pouvoir facilement faire, c'est changer d'objet désigné (mais avec les placement new, je crois que Gabriel m'avais montré que c'étais possible, mais ça devient un usage un peu avancé pour moi).
#include <iostream> using namespace std;
int main() { int i; int &j= i; j= 5; cout<<"i ="<<i<<endl;
}
-- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <41e28608$0$31781$626a14ce@news.free.fr>, xavier wrote:
Amerio a dis le 10/01/2005 14:09:
t = *t0; // ca ne plante pas a l'execution !
Attention, cette instruction est équivalent à :
t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Si, on peut modifier l'objet désigné par une référence.
Ce qu'on ne doit pas pouvoir facilement faire, c'est changer
d'objet désigné (mais avec les placement new, je crois que
Gabriel m'avais montré que c'étais possible, mais ça devient
un usage un peu avancé pour moi).
#include <iostream>
using namespace std;
int main()
{
int i;
int &j= i;
j= 5;
cout<<"i ="<<i<<endl;
}
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Attention, cette instruction est équivalent à : t.operator=(*t0);
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Si, on peut modifier l'objet désigné par une référence. Ce qu'on ne doit pas pouvoir facilement faire, c'est changer d'objet désigné (mais avec les placement new, je crois que Gabriel m'avais montré que c'étais possible, mais ça devient un usage un peu avancé pour moi).
#include <iostream> using namespace std;
int main() { int i; int &j= i; j= 5; cout<<"i ="<<i<<endl;
}
-- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
xavier
Marc Boyer a dis le 10/01/2005 15:49:
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence. Si, on peut modifier l'objet désigné par une référence.
Bien sûr, autant pour moi, ma formulation était vraiment malheureuse. J'espère ne pas avoir apporté trop de confusion.
"On peut modifier la valeur de l'objet référencé, pas la référence elle-même". Est-ce mieux? sachant que j'utilise déjà des guillemets autour du très approximatif "pointé".
xavier
Marc Boyer a dis le 10/01/2005 15:49:
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence.
Si, on peut modifier l'objet désigné par une référence.
Bien sûr, autant pour moi, ma formulation était vraiment malheureuse.
J'espère ne pas avoir apporté trop de confusion.
"On peut modifier la valeur de l'objet référencé, pas la référence
elle-même". Est-ce mieux? sachant que j'utilise déjà des guillemets
autour du très approximatif "pointé".
Tu ne peux pas modifier l'espace mémoire "pointé" par une référence. Si, on peut modifier l'objet désigné par une référence.
Bien sûr, autant pour moi, ma formulation était vraiment malheureuse. J'espère ne pas avoir apporté trop de confusion.
"On peut modifier la valeur de l'objet référencé, pas la référence elle-même". Est-ce mieux? sachant que j'utilise déjà des guillemets autour du très approximatif "pointé".
xavier
kanze
Marc Boyer wrote:
In article <41e27eb4$0$19589$, Amerio wrote:
J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL :
void fct( Toto* t) // t peut être NULL, fct doit vérifier void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ; int main() { Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution !
Sauf qu'à partir du moment ou tu as écrit *t0, tu as provoqué un Undefined behavior, donc ce qui se passe désormais peut-être n'importe quoi.
La question est, qu'est-ce qu'il essaie de montrer comme point. Il commence en parlant de NULL, et qu'on ne peut pas avoir des références nulle, mais son programme déréférence un pointeur NULL, ce qui n'a rien à voir avec des références.
Tu pourrais aussi écrire memset(&t, 0, sizeof(Toto&) ); tu aurais surement le même ganre de comportement.
Je le doute. Il n'y aurait de problème ici que si Toto a des invariantes de classe qui sont violées en mettant tous ses octets à zéro.
// si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à l'affectation !
Chez moi, ça plante à l'affectation -- je ne peux même pas lire à travers un pointeur nul. Mais c'est un comportement indéfini. Il peut se passer n'importe quoi.
}
Donc je peux passer une référence invalide (NULL) à une fonction !
Pas légalement. Mais je ne vois pas de rapport avec le code dans l'exemple.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Marc Boyer wrote:
In article <41e27eb4$0$19589$636a15ce@news.free.fr>, Amerio wrote:
J'ai toujours considéré qu'il fallait utiliser une référence
(&) quand on voulait garantir à une fonction qu'un paramètre
ne pouvait pas être NULL :
void fct( Toto* t) // t peut être NULL, fct doit vérifier
void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune
erreur :
struct Toto { ... } ;
int main()
{
Toto t1;
Toto *t0 = 0;
Toto& t = t1; // ok tout va bien
t = *t0; // ca ne plante pas a l'execution !
Sauf qu'à partir du moment ou tu as écrit *t0, tu as
provoqué un Undefined behavior, donc ce qui se passe désormais
peut-être n'importe quoi.
La question est, qu'est-ce qu'il essaie de montrer comme point.
Il commence en parlant de NULL, et qu'on ne peut pas avoir des
références nulle, mais son programme déréférence un pointeur
NULL, ce qui n'a rien à voir avec des références.
Tu pourrais aussi écrire
memset(&t, 0, sizeof(Toto&) );
tu aurais surement le même ganre de comportement.
Je le doute. Il n'y aurait de problème ici que si Toto a des
invariantes de classe qui sont violées en mettant tous ses
octets à zéro.
// si j'utilise t, maintenant, ca plantera ! mais ca ne
plante pas à l'affectation !
Chez moi, ça plante à l'affectation -- je ne peux même pas lire
à travers un pointeur nul. Mais c'est un comportement indéfini.
Il peut se passer n'importe quoi.
}
Donc je peux passer une référence invalide (NULL) à une
fonction !
Pas légalement. Mais je ne vois pas de rapport avec le code dans
l'exemple.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J'ai toujours considéré qu'il fallait utiliser une référence (&) quand on voulait garantir à une fonction qu'un paramètre ne pouvait pas être NULL :
void fct( Toto* t) // t peut être NULL, fct doit vérifier void fct( Toto& t) // t est forcément valide
Hors, en faisant un test, le code suivant ne produit aucune erreur :
struct Toto { ... } ; int main() { Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution !
Sauf qu'à partir du moment ou tu as écrit *t0, tu as provoqué un Undefined behavior, donc ce qui se passe désormais peut-être n'importe quoi.
La question est, qu'est-ce qu'il essaie de montrer comme point. Il commence en parlant de NULL, et qu'on ne peut pas avoir des références nulle, mais son programme déréférence un pointeur NULL, ce qui n'a rien à voir avec des références.
Tu pourrais aussi écrire memset(&t, 0, sizeof(Toto&) ); tu aurais surement le même ganre de comportement.
Je le doute. Il n'y aurait de problème ici que si Toto a des invariantes de classe qui sont violées en mettant tous ses octets à zéro.
// si j'utilise t, maintenant, ca plantera ! mais ca ne plante pas à l'affectation !
Chez moi, ça plante à l'affectation -- je ne peux même pas lire à travers un pointeur nul. Mais c'est un comportement indéfini. Il peut se passer n'importe quoi.
}
Donc je peux passer une référence invalide (NULL) à une fonction !
Pas légalement. Mais je ne vois pas de rapport avec le code dans l'exemple.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Marc Boyer
wrote:
Marc Boyer wrote:
In article <41e27eb4$0$19589$, Amerio wrote:
Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution ! [SNIP]
La question est, qu'est-ce qu'il essaie de montrer comme point. Il commence en parlant de NULL, et qu'on ne peut pas avoir des références nulle, mais son programme déréférence un pointeur NULL, ce qui n'a rien à voir avec des références.
Oui et non. Non dans le sens où ce sont des choses différentes. Mais oui quand même dans le sens ou je ne serais pas étonné qu'un compilateur représente en interne un pointeur et une référence de la même manière, et qu'il optimise une écriture du genre Toto &t= *t; en une copie interne de pointeur à pointeur.
Tu pourrais aussi écrire memset(&t, 0, sizeof(Toto&) ); tu aurais surement le même ganre de comportement.
Je le doute. Il n'y aurait de problème ici que si Toto a des invariantes de classe qui sont violées en mettant tous ses octets à zéro.
Je pense que j'ai écris une grosse bétise sur ces lignes là.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
kanze@gabi-soft.fr wrote:
Marc Boyer wrote:
In article <41e27eb4$0$19589$636a15ce@news.free.fr>, Amerio wrote:
Toto t1;
Toto *t0 = 0;
Toto& t = t1; // ok tout va bien
t = *t0; // ca ne plante pas a l'execution !
[SNIP]
La question est, qu'est-ce qu'il essaie de montrer comme point.
Il commence en parlant de NULL, et qu'on ne peut pas avoir des
références nulle, mais son programme déréférence un pointeur
NULL, ce qui n'a rien à voir avec des références.
Oui et non.
Non dans le sens où ce sont des choses différentes.
Mais oui quand même dans le sens ou je ne serais pas
étonné qu'un compilateur représente en interne un pointeur
et une référence de la même manière, et qu'il optimise
une écriture du genre
Toto &t= *t;
en une copie interne de pointeur à pointeur.
Tu pourrais aussi écrire
memset(&t, 0, sizeof(Toto&) );
tu aurais surement le même ganre de comportement.
Je le doute. Il n'y aurait de problème ici que si Toto a des
invariantes de classe qui sont violées en mettant tous ses
octets à zéro.
Je pense que j'ai écris une grosse bétise sur ces lignes là.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Toto t1; Toto *t0 = 0; Toto& t = t1; // ok tout va bien t = *t0; // ca ne plante pas a l'execution ! [SNIP]
La question est, qu'est-ce qu'il essaie de montrer comme point. Il commence en parlant de NULL, et qu'on ne peut pas avoir des références nulle, mais son programme déréférence un pointeur NULL, ce qui n'a rien à voir avec des références.
Oui et non. Non dans le sens où ce sont des choses différentes. Mais oui quand même dans le sens ou je ne serais pas étonné qu'un compilateur représente en interne un pointeur et une référence de la même manière, et qu'il optimise une écriture du genre Toto &t= *t; en une copie interne de pointeur à pointeur.
Tu pourrais aussi écrire memset(&t, 0, sizeof(Toto&) ); tu aurais surement le même ganre de comportement.
Je le doute. Il n'y aurait de problème ici que si Toto a des invariantes de classe qui sont violées en mettant tous ses octets à zéro.
Je pense que j'ai écris une grosse bétise sur ces lignes là.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Andre Heinen
On Mon, 10 Jan 2005 15:39:34 +0100, "Amerio" wrote:
Effectivement, je vois maintenant mon erreur ! Ca va tout de suite mieux quand on considere une reference comme un alias...
Oui.
(on ne devrait donc pas comparer l'usage de Toto& à celui de Toto*, mais à celui de Toto* const !)
Je pense que tu aurais une meilleure idée de ce qu'est une référence si tu la comparais non pas à un pointeur, mais un autre nom pour une donnée. Par exemple:
int i; int* p = &i; int& r = i;
r est maintenant un autre nom pour i, et est beaucoup plus similaire à i qu'à p.
-- André Heinen Mon e-mail, encodé ROT13: n qbg urvara ng rhebcrnayvax qbg pbz La FAQ: http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/
On Mon, 10 Jan 2005 15:39:34 +0100, "Amerio" <amerio@hotmail.com>
wrote:
Effectivement, je vois maintenant mon erreur !
Ca va tout de suite mieux quand on considere une reference comme un alias...
Oui.
(on ne devrait donc pas comparer l'usage de Toto& à celui de Toto*, mais à
celui de Toto* const !)
Je pense que tu aurais une meilleure idée de ce qu'est une
référence si tu la comparais non pas à un pointeur, mais un autre
nom pour une donnée. Par exemple:
int i;
int* p = &i;
int& r = i;
r est maintenant un autre nom pour i, et est beaucoup plus
similaire à i qu'à p.
--
André Heinen
Mon e-mail, encodé ROT13: n qbg urvara ng rhebcrnayvax qbg pbz
La FAQ: http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/
On Mon, 10 Jan 2005 15:39:34 +0100, "Amerio" wrote:
Effectivement, je vois maintenant mon erreur ! Ca va tout de suite mieux quand on considere une reference comme un alias...
Oui.
(on ne devrait donc pas comparer l'usage de Toto& à celui de Toto*, mais à celui de Toto* const !)
Je pense que tu aurais une meilleure idée de ce qu'est une référence si tu la comparais non pas à un pointeur, mais un autre nom pour une donnée. Par exemple:
int i; int* p = &i; int& r = i;
r est maintenant un autre nom pour i, et est beaucoup plus similaire à i qu'à p.
-- André Heinen Mon e-mail, encodé ROT13: n qbg urvara ng rhebcrnayvax qbg pbz La FAQ: http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/
