En portant du code =E9crit "=E0 la C" vers une approche un peu plus OO,
j'ai un petit peu de mal avec le concept de r=E9f=E9rence (je veux dire :
pourquoi utiliser des r=E9f=E9rences plut=F4t que des pointeurs ?)
Existe-t-il quelques arguments "massues", concr=E8tement
explicables avec du code, qui pourraient me convaincre
de syst=E9matiquement utiliser des r=E9f=E9rences, alors que
j'ai une grosse tendance naturelle (qui me vient du C) =E0
utiliser les pointeurs ?
--
"Remember, objects in the mirror are actually behind you."
-
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Boyer
Le 20-11-2006, Manuel Leclerc a écrit :
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai un petit peu de mal avec le concept de référence (je veux dire : pourquoi utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables avec du code, qui pourraient me convaincre de systématiquement utiliser des références, alors que j'ai une grosse tendance naturelle (qui me vient du C) à utiliser les pointeurs ?
Il n'existe aucun argument "massue": de même que ce qu'on peut faire en C, on pouvait le faire en assembleur, ce qu'on peut faire en C++, on peut le faire en C. Les références 'aident' le programmeur contre les erreurs d'étourderie.
Quels sont les points forts des références: a) on ne peut pas oublier de les initialiser b) elles offrent une syntaxe plus facile, et protègent contre les erreurs de typage ex1: int* p; p= 0; /* est-ce vraiment ça ou *p=0 qu'il voulait */ ex2: int **p; /* Qu'est-ce qu'il veut faire ? */
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 20-11-2006, Manuel Leclerc <manuel.leclerc@alussinan.org> a écrit :
En portant du code écrit "à la C" vers une approche un peu plus OO,
j'ai un petit peu de mal avec le concept de référence (je veux dire :
pourquoi utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement
explicables avec du code, qui pourraient me convaincre
de systématiquement utiliser des références, alors que
j'ai une grosse tendance naturelle (qui me vient du C) à
utiliser les pointeurs ?
Il n'existe aucun argument "massue": de même que ce qu'on
peut faire en C, on pouvait le faire en assembleur, ce qu'on
peut faire en C++, on peut le faire en C.
Les références 'aident' le programmeur contre les erreurs
d'étourderie.
Quels sont les points forts des références:
a) on ne peut pas oublier de les initialiser
b) elles offrent une syntaxe plus facile, et protègent
contre les erreurs de typage
ex1: int* p;
p= 0; /* est-ce vraiment ça ou *p=0 qu'il voulait */
ex2: int **p; /* Qu'est-ce qu'il veut faire ? */
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai un petit peu de mal avec le concept de référence (je veux dire : pourquoi utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables avec du code, qui pourraient me convaincre de systématiquement utiliser des références, alors que j'ai une grosse tendance naturelle (qui me vient du C) à utiliser les pointeurs ?
Il n'existe aucun argument "massue": de même que ce qu'on peut faire en C, on pouvait le faire en assembleur, ce qu'on peut faire en C++, on peut le faire en C. Les références 'aident' le programmeur contre les erreurs d'étourderie.
Quels sont les points forts des références: a) on ne peut pas oublier de les initialiser b) elles offrent une syntaxe plus facile, et protègent contre les erreurs de typage ex1: int* p; p= 0; /* est-ce vraiment ça ou *p=0 qu'il voulait */ ex2: int **p; /* Qu'est-ce qu'il veut faire ? */
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Jean-Marc Bourguet
"Manuel Leclerc" writes:
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai un petit peu de mal avec le concept de référence (je veux dire : pourquoi utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables avec du code, qui pourraient me convaincre de systématiquement utiliser des références, alors que j'ai une grosse tendance naturelle (qui me vient du C) à utiliser les pointeurs ?
Les references on les utilise dans quatres contextes:
- comme parametres. Hors les cas ou il n'y a pas le choix (pas moyen de faire un constructeur de copie qui prenne son argument autrement que par reference, surcharger les operateurs a beaucoup moins de sens sans les references, les references constantes peuvent etre liees a des temporaires -- prendre l'adresse d'un temporaire est beaucou plus douteux dans les cas ou c'est autorise-- il n'y a pas d'equivalent a NULL pour les references), l'utilisation d'une reference ou d'un pointeur a peu de consequences techniques. Le choix de l'un ou l'autre va resulter de ce qu'on veut communiquer a l'appelant -- et le message passe resulte des conventions du projet.
Certains utilisent les references systematiquement quand un objet est obligatoire (donc qu'on ne pourrait pas passer NULL si l'argument etait un pointeur). C'est simple a expliquer mais je n'aime pas tellement ce choix. Sincerement, un code comme: void Dispose(Foo& f) { delete &f; } ne me plait pas, et ce qui ne me plait pas c'est que j'ai l'impression qu'on se base sur quelque chose d'accidentel parce que c'est facile a exprimer plutot qu'une caracteristique essentielle qui peut etre plus importante a communiquer (si ca marche, c'est qu'il y a correlation entre les deux).
J'ai deja donne ma regle a moi dans le passe, on peut l'exprimer simplement ainsi: ne pas devoir prendre l'adresse d'une variable locale, toujours pouvoir passer une variable locale a une reference. Le message est que la fonction va agir sur la reference pendant son execution mais ne va pas faire des choses qui entrainerait un dereferencement apres la fin de celle-ci.
- comme resultats d'une fonction. Pour moi, la duree de validite d'une reference retournee est plus courte que la duree de validite d'un pointeur. Dans le premier cas, elle est vraissemblablement controllee par le systeme retournant la reference; dans le second par le systeme recevant le pointeur.
- comme variables. J'ai tendance a ne pas utiliser des references comme variables. On alors avec une localite tres petite, pour simplifier une expression.
- comme membres. On se retrouve un peu dans le cas des parametres, parce que si on a un membre qui est une reference, sauf cas particulier, il faut avoir une reference comme parametre des constructeurs. Ma regle simple couvre assez bien les cas ou je les utilises. L'exemple paramdigmatique serait vraissemblablement une classe RAI pour acquerir et liberer un mutex. L'idee est que l'objet va agir sur la reference pendant la duree de sa vie mais ne va pas faire des choses qui entrainerait un dereferencement apres apres celle-ci.
Je crois que le probleme de fond, c'est celui de la politique de gestion de duree de vie. Avoir differents moyens de specifier un objet (pointeur, reference, pointeurs intelligents, variables locales, ...) permet de documenter quelle politique est utilisee, permet de faire controller une partie de celle-ci par le compilateur, permet de faire appliquer une partie de celle-ci par le compilateur.
N'avoir qu'un moyen, comme dans certains langages, force la documentation de ces choix d'une autre maniere qui ne peut pas etre verifiee statiquement d'une part, et que le compilateur doit redecouvrir pour generer du code efficace d'autre part (voir les papiers sur les techniques pour redecouvrir qu'un objet est automatique dans les langages n'ayant pas cette notion).
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai
un petit peu de mal avec le concept de référence (je veux dire : pourquoi
utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables avec
du code, qui pourraient me convaincre de systématiquement utiliser des
références, alors que j'ai une grosse tendance naturelle (qui me vient du
C) à utiliser les pointeurs ?
Les references on les utilise dans quatres contextes:
- comme parametres. Hors les cas ou il n'y a pas le choix (pas moyen de
faire un constructeur de copie qui prenne son argument autrement que par
reference, surcharger les operateurs a beaucoup moins de sens sans les
references, les references constantes peuvent etre liees a des
temporaires -- prendre l'adresse d'un temporaire est beaucou plus douteux
dans les cas ou c'est autorise-- il n'y a pas d'equivalent a NULL pour
les references), l'utilisation d'une reference ou d'un pointeur a peu de
consequences techniques. Le choix de l'un ou l'autre va resulter de ce
qu'on veut communiquer a l'appelant -- et le message passe resulte des
conventions du projet.
Certains utilisent les references systematiquement quand un objet est
obligatoire (donc qu'on ne pourrait pas passer NULL si l'argument etait
un pointeur). C'est simple a expliquer mais je n'aime pas tellement ce
choix. Sincerement, un code comme:
void Dispose(Foo& f) { delete &f; }
ne me plait pas, et ce qui ne me plait pas c'est que j'ai l'impression
qu'on se base sur quelque chose d'accidentel parce que c'est facile a
exprimer plutot qu'une caracteristique essentielle qui peut etre plus
importante a communiquer (si ca marche, c'est qu'il y a correlation entre
les deux).
J'ai deja donne ma regle a moi dans le passe, on peut l'exprimer
simplement ainsi: ne pas devoir prendre l'adresse d'une variable locale,
toujours pouvoir passer une variable locale a une reference. Le message
est que la fonction va agir sur la reference pendant son execution mais
ne va pas faire des choses qui entrainerait un dereferencement apres la
fin de celle-ci.
- comme resultats d'une fonction. Pour moi, la duree de validite d'une
reference retournee est plus courte que la duree de validite d'un
pointeur. Dans le premier cas, elle est vraissemblablement controllee
par le systeme retournant la reference; dans le second par le systeme
recevant le pointeur.
- comme variables. J'ai tendance a ne pas utiliser des references comme
variables. On alors avec une localite tres petite, pour simplifier une
expression.
- comme membres. On se retrouve un peu dans le cas des parametres, parce
que si on a un membre qui est une reference, sauf cas particulier, il
faut avoir une reference comme parametre des constructeurs. Ma regle
simple couvre assez bien les cas ou je les utilises. L'exemple
paramdigmatique serait vraissemblablement une classe RAI pour acquerir et
liberer un mutex. L'idee est que l'objet va agir sur la reference
pendant la duree de sa vie mais ne va pas faire des choses qui
entrainerait un dereferencement apres apres celle-ci.
Je crois que le probleme de fond, c'est celui de la politique de gestion de
duree de vie. Avoir differents moyens de specifier un objet (pointeur,
reference, pointeurs intelligents, variables locales, ...) permet de
documenter quelle politique est utilisee, permet de faire controller une
partie de celle-ci par le compilateur, permet de faire appliquer une partie
de celle-ci par le compilateur.
N'avoir qu'un moyen, comme dans certains langages, force la documentation
de ces choix d'une autre maniere qui ne peut pas etre verifiee statiquement
d'une part, et que le compilateur doit redecouvrir pour generer du code
efficace d'autre part (voir les papiers sur les techniques pour redecouvrir
qu'un objet est automatique dans les langages n'ayant pas cette notion).
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai un petit peu de mal avec le concept de référence (je veux dire : pourquoi utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables avec du code, qui pourraient me convaincre de systématiquement utiliser des références, alors que j'ai une grosse tendance naturelle (qui me vient du C) à utiliser les pointeurs ?
Les references on les utilise dans quatres contextes:
- comme parametres. Hors les cas ou il n'y a pas le choix (pas moyen de faire un constructeur de copie qui prenne son argument autrement que par reference, surcharger les operateurs a beaucoup moins de sens sans les references, les references constantes peuvent etre liees a des temporaires -- prendre l'adresse d'un temporaire est beaucou plus douteux dans les cas ou c'est autorise-- il n'y a pas d'equivalent a NULL pour les references), l'utilisation d'une reference ou d'un pointeur a peu de consequences techniques. Le choix de l'un ou l'autre va resulter de ce qu'on veut communiquer a l'appelant -- et le message passe resulte des conventions du projet.
Certains utilisent les references systematiquement quand un objet est obligatoire (donc qu'on ne pourrait pas passer NULL si l'argument etait un pointeur). C'est simple a expliquer mais je n'aime pas tellement ce choix. Sincerement, un code comme: void Dispose(Foo& f) { delete &f; } ne me plait pas, et ce qui ne me plait pas c'est que j'ai l'impression qu'on se base sur quelque chose d'accidentel parce que c'est facile a exprimer plutot qu'une caracteristique essentielle qui peut etre plus importante a communiquer (si ca marche, c'est qu'il y a correlation entre les deux).
J'ai deja donne ma regle a moi dans le passe, on peut l'exprimer simplement ainsi: ne pas devoir prendre l'adresse d'une variable locale, toujours pouvoir passer une variable locale a une reference. Le message est que la fonction va agir sur la reference pendant son execution mais ne va pas faire des choses qui entrainerait un dereferencement apres la fin de celle-ci.
- comme resultats d'une fonction. Pour moi, la duree de validite d'une reference retournee est plus courte que la duree de validite d'un pointeur. Dans le premier cas, elle est vraissemblablement controllee par le systeme retournant la reference; dans le second par le systeme recevant le pointeur.
- comme variables. J'ai tendance a ne pas utiliser des references comme variables. On alors avec une localite tres petite, pour simplifier une expression.
- comme membres. On se retrouve un peu dans le cas des parametres, parce que si on a un membre qui est une reference, sauf cas particulier, il faut avoir une reference comme parametre des constructeurs. Ma regle simple couvre assez bien les cas ou je les utilises. L'exemple paramdigmatique serait vraissemblablement une classe RAI pour acquerir et liberer un mutex. L'idee est que l'objet va agir sur la reference pendant la duree de sa vie mais ne va pas faire des choses qui entrainerait un dereferencement apres apres celle-ci.
Je crois que le probleme de fond, c'est celui de la politique de gestion de duree de vie. Avoir differents moyens de specifier un objet (pointeur, reference, pointeurs intelligents, variables locales, ...) permet de documenter quelle politique est utilisee, permet de faire controller une partie de celle-ci par le compilateur, permet de faire appliquer une partie de celle-ci par le compilateur.
N'avoir qu'un moyen, comme dans certains langages, force la documentation de ces choix d'une autre maniere qui ne peut pas etre verifiee statiquement d'une part, et que le compilateur doit redecouvrir pour generer du code efficace d'autre part (voir les papiers sur les techniques pour redecouvrir qu'un objet est automatique dans les langages n'ayant pas cette notion).
A+
-- Jean-Marc
meow
Pour moi il y a essentiellement l'utilisation comme paramètre de fonctions. ça permet d'avoir une écriture plus fluide : plus besoin de déréférencer, on bosse sur une sorte d'alias.
Pour moi il y a essentiellement l'utilisation comme paramètre de
fonctions. ça permet d'avoir une écriture plus fluide : plus besoin
de déréférencer, on bosse sur une sorte d'alias.
Pour moi il y a essentiellement l'utilisation comme paramètre de fonctions. ça permet d'avoir une écriture plus fluide : plus besoin de déréférencer, on bosse sur une sorte d'alias.
James Kanze
Jean-Marc Bourguet wrote:
"Manuel Leclerc" writes:
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai un petit peu de mal avec le concept de référence (je veux dire : po urquoi utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables av ec du code, qui pourraient me convaincre de systématiquement utiliser des références, alors que j'ai une grosse tendance naturelle (qui me vi ent du C) à utiliser les pointeurs ?
Les references on les utilise dans quatres contextes:
[...]
- comme membres. On se retrouve un peu dans le cas des parametres, parce que si on a un membre qui est une reference, sauf cas particulier, il faut avoir une reference comme parametre des constructeurs. Ma regle simple couvre assez bien les cas ou je les utilises. L'exemple paramdigmatique serait vraissemblablement une classe RAI pour acquerir et liberer un mutex. L'idee est que l'objet va agir sur la reference pendant la duree de sa vie mais ne va pas faire des choses qui entrainerait un dereferencement apres apres celle-ci.
Il ne faut pas oublier que si on utilise des références comme membres, l'affectation devient assez problèmatique. Du coup, il m'arrive souvent à utiliser un pointeur dans l'objet, tandis que le paramètre du constructeur est une référence.
-- James Kanze (GABI Software) email: 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
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai
un petit peu de mal avec le concept de référence (je veux dire : po urquoi
utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables av ec
du code, qui pourraient me convaincre de systématiquement utiliser des
références, alors que j'ai une grosse tendance naturelle (qui me vi ent du
C) à utiliser les pointeurs ?
Les references on les utilise dans quatres contextes:
[...]
- comme membres. On se retrouve un peu dans le cas des parametres, parce
que si on a un membre qui est une reference, sauf cas particulier, il
faut avoir une reference comme parametre des constructeurs. Ma regle
simple couvre assez bien les cas ou je les utilises. L'exemple
paramdigmatique serait vraissemblablement une classe RAI pour acquerir et
liberer un mutex. L'idee est que l'objet va agir sur la reference
pendant la duree de sa vie mais ne va pas faire des choses qui
entrainerait un dereferencement apres apres celle-ci.
Il ne faut pas oublier que si on utilise des références comme
membres, l'affectation devient assez problèmatique. Du coup, il
m'arrive souvent à utiliser un pointeur dans l'objet, tandis que
le paramètre du constructeur est une référence.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
En portant du code écrit "à la C" vers une approche un peu plus OO, j'ai un petit peu de mal avec le concept de référence (je veux dire : po urquoi utiliser des références plutôt que des pointeurs ?)
Existe-t-il quelques arguments "massues", concrètement explicables av ec du code, qui pourraient me convaincre de systématiquement utiliser des références, alors que j'ai une grosse tendance naturelle (qui me vi ent du C) à utiliser les pointeurs ?
Les references on les utilise dans quatres contextes:
[...]
- comme membres. On se retrouve un peu dans le cas des parametres, parce que si on a un membre qui est une reference, sauf cas particulier, il faut avoir une reference comme parametre des constructeurs. Ma regle simple couvre assez bien les cas ou je les utilises. L'exemple paramdigmatique serait vraissemblablement une classe RAI pour acquerir et liberer un mutex. L'idee est que l'objet va agir sur la reference pendant la duree de sa vie mais ne va pas faire des choses qui entrainerait un dereferencement apres apres celle-ci.
Il ne faut pas oublier que si on utilise des références comme membres, l'affectation devient assez problèmatique. Du coup, il m'arrive souvent à utiliser un pointeur dans l'objet, tandis que le paramètre du constructeur est une référence.
-- James Kanze (GABI Software) email: 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
