si je comprends bien :
FonctionUn renvoie par valeur la reference de l'objet pour la
construction de sa copie.
FonctionDeux renvoie le parametre par dereferencement du pointeur.
Question : Pourquoi dans le commentaire du listing ci-dessous pour
FonctionDeux est-il est précisé par reference ?
Question : Dans l'exposition de mon problème, ai-je bien assimilé la
notion de pointeur et reference ? J'ai l'impression que ce n'est pas
clair... Si je m'embrouille un retour et mise en garde serait fort
sympatique.
si je comprends bien :
FonctionUn renvoie par valeur la reference de l'objet pour la
construction de sa copie.
FonctionDeux renvoie le parametre par dereferencement du pointeur.
Question : Pourquoi dans le commentaire du listing ci-dessous pour
FonctionDeux est-il est précisé par reference ?
Question : Dans l'exposition de mon problème, ai-je bien assimilé la
notion de pointeur et reference ? J'ai l'impression que ce n'est pas
clair... Si je m'embrouille un retour et mise en garde serait fort
sympatique.
si je comprends bien :
FonctionUn renvoie par valeur la reference de l'objet pour la
construction de sa copie.
FonctionDeux renvoie le parametre par dereferencement du pointeur.
Question : Pourquoi dans le commentaire du listing ci-dessous pour
FonctionDeux est-il est précisé par reference ?
Question : Dans l'exposition de mon problème, ai-je bien assimilé la
notion de pointeur et reference ? J'ai l'impression que ce n'est pas
clair... Si je m'embrouille un retour et mise en garde serait fort
sympatique.
Si le code suivant est extrait du bouquin sur lequel tu apprends, change
de bouquins: ces exemples me semblent fortement confusogenes.
Si l'auteur attaque directement avec une
classe, un constructeur de copie, et des pointeurs, ca ne me surprend pas
outre mesure que tu sois perdu.
Si le code suivant est extrait du bouquin sur lequel tu apprends, change
de bouquins: ces exemples me semblent fortement confusogenes.
Si l'auteur attaque directement avec une
classe, un constructeur de copie, et des pointeurs, ca ne me surprend pas
outre mesure que tu sois perdu.
Si le code suivant est extrait du bouquin sur lequel tu apprends, change
de bouquins: ces exemples me semblent fortement confusogenes.
Si l'auteur attaque directement avec une
classe, un constructeur de copie, et des pointeurs, ca ne me surprend pas
outre mesure que tu sois perdu.
Faudrait que tu nous dises ce qu'il y a dans ton bouquin sur le
passage par valeur et par reference. Si l'auteur attaque directement
avec une classe, un constructeur de copie, et des pointeurs, ca ne me
surprend pas outre mesure que tu sois perdu.
Pour plus te repondre, faudra sans doute des questions et des exemples
plus simples, qui ne melangent pas plein de concepts d'un coup.
Faudrait que tu nous dises ce qu'il y a dans ton bouquin sur le
passage par valeur et par reference. Si l'auteur attaque directement
avec une classe, un constructeur de copie, et des pointeurs, ca ne me
surprend pas outre mesure que tu sois perdu.
Pour plus te repondre, faudra sans doute des questions et des exemples
plus simples, qui ne melangent pas plein de concepts d'un coup.
Faudrait que tu nous dises ce qu'il y a dans ton bouquin sur le
passage par valeur et par reference. Si l'auteur attaque directement
avec une classe, un constructeur de copie, et des pointeurs, ca ne me
surprend pas outre mesure que tu sois perdu.
Pour plus te repondre, faudra sans doute des questions et des exemples
plus simples, qui ne melangent pas plein de concepts d'un coup.
l'auteur expose la problématique des classe, en abordant succinctement
le constructeur de copie qui sera aborde au chapitre suivant. le
theoreme "constructeur de copie" etant ; celui -ci est appele a chaque
fois qu'une copie temporaire de l'objet est place sur la pile.
Lorsque cet objet temporaire est detruit a la fin de l'execution de la
fonction, son destructeur est appelé. Si la fonction renvoie un objet
par valeur, il faut egalement faire copie de cet objet et le detruire.
Avec des objets volumineux ces appels de constructeurs et destructeurs
peuvent avoir un impact sur la vitesse d execution du programme et son
utilisation de la memoire.
l'auteur expose la problématique des classe, en abordant succinctement
le constructeur de copie qui sera aborde au chapitre suivant. le
theoreme "constructeur de copie" etant ; celui -ci est appele a chaque
fois qu'une copie temporaire de l'objet est place sur la pile.
Lorsque cet objet temporaire est detruit a la fin de l'execution de la
fonction, son destructeur est appelé. Si la fonction renvoie un objet
par valeur, il faut egalement faire copie de cet objet et le detruire.
Avec des objets volumineux ces appels de constructeurs et destructeurs
peuvent avoir un impact sur la vitesse d execution du programme et son
utilisation de la memoire.
l'auteur expose la problématique des classe, en abordant succinctement
le constructeur de copie qui sera aborde au chapitre suivant. le
theoreme "constructeur de copie" etant ; celui -ci est appele a chaque
fois qu'une copie temporaire de l'objet est place sur la pile.
Lorsque cet objet temporaire est detruit a la fin de l'execution de la
fonction, son destructeur est appelé. Si la fonction renvoie un objet
par valeur, il faut egalement faire copie de cet objet et le detruire.
Avec des objets volumineux ces appels de constructeurs et destructeurs
peuvent avoir un impact sur la vitesse d execution du programme et son
utilisation de la memoire.
On Mon, 6 Jun 2011 22:21:40 +0000 (UTC), (Marc Espie):
>Si le code suivant est extrait du bouquin sur lequel tu apprends,
>change de bouquins: ces exemples me semblent fortement confusogenes.
Effectivement, c'est le merdier.
À ma connaissance, le seul bouquin valable pour enseigner le C++ aux
débutants est Accelerated C++, de Koenig & Moo.
>Si l'auteur attaque directement avec une
>classe, un constructeur de copie, et des pointeurs, ca ne me
>surprend pas outre mesure que tu sois perdu.
D'autant que ça ne servira pas avant un moment. Dans la plupart des
cas (surtout au début), quand on est tenté d'utiliser un constructeur
de copie, c'est qu'on fait beaucoup trop compliqué, ou bien qu'un
réinvente la roue (typiquement, on reprogramme à la main un pointeur
intelligent).
On Mon, 6 Jun 2011 22:21:40 +0000 (UTC), espie@lain.home (Marc Espie):
>Si le code suivant est extrait du bouquin sur lequel tu apprends,
>change de bouquins: ces exemples me semblent fortement confusogenes.
Effectivement, c'est le merdier.
À ma connaissance, le seul bouquin valable pour enseigner le C++ aux
débutants est Accelerated C++, de Koenig & Moo.
>Si l'auteur attaque directement avec une
>classe, un constructeur de copie, et des pointeurs, ca ne me
>surprend pas outre mesure que tu sois perdu.
D'autant que ça ne servira pas avant un moment. Dans la plupart des
cas (surtout au début), quand on est tenté d'utiliser un constructeur
de copie, c'est qu'on fait beaucoup trop compliqué, ou bien qu'un
réinvente la roue (typiquement, on reprogramme à la main un pointeur
intelligent).
On Mon, 6 Jun 2011 22:21:40 +0000 (UTC), (Marc Espie):
>Si le code suivant est extrait du bouquin sur lequel tu apprends,
>change de bouquins: ces exemples me semblent fortement confusogenes.
Effectivement, c'est le merdier.
À ma connaissance, le seul bouquin valable pour enseigner le C++ aux
débutants est Accelerated C++, de Koenig & Moo.
>Si l'auteur attaque directement avec une
>classe, un constructeur de copie, et des pointeurs, ca ne me
>surprend pas outre mesure que tu sois perdu.
D'autant que ça ne servira pas avant un moment. Dans la plupart des
cas (surtout au début), quand on est tenté d'utiliser un constructeur
de copie, c'est qu'on fait beaucoup trop compliqué, ou bien qu'un
réinvente la roue (typiquement, on reprogramme à la main un pointeur
intelligent).
le trois quart des choses exprimées est abstrait pour moi :) je tag
précieusement ce post pour, un jour ou cela devient comprehensible je
le retrouve. L'héritage et le polymorphysme ne sont abordé
respectivement que dans 3 et 5 chapitres.
J'en ai compris le principe, cela ressemble a la fin de mon chapitre...
le trois quart des choses exprimées est abstrait pour moi :) je tag
précieusement ce post pour, un jour ou cela devient comprehensible je
le retrouve. L'héritage et le polymorphysme ne sont abordé
respectivement que dans 3 et 5 chapitres.
J'en ai compris le principe, cela ressemble a la fin de mon chapitre...
le trois quart des choses exprimées est abstrait pour moi :) je tag
précieusement ce post pour, un jour ou cela devient comprehensible je
le retrouve. L'héritage et le polymorphysme ne sont abordé
respectivement que dans 3 et 5 chapitres.
J'en ai compris le principe, cela ressemble a la fin de mon chapitre...
In article ,
Olivier BURELLI wrote:
>l'auteur expose la problématique des classe, en abordant
>succinctement le constructeur de copie qui sera aborde au chapitre
>suivant. le theoreme "constructeur de copie" etant ; celui -ci est
>appele a chaque fois qu'une copie temporaire de l'objet est place
>sur la pile.
>
>Lorsque cet objet temporaire est detruit a la fin de l'execution de
>la fonction, son destructeur est appelé. Si la fonction renvoie un
>objet par valeur, il faut egalement faire copie de cet objet et le
>detruire.
>
>Avec des objets volumineux ces appels de constructeurs et
>destructeurs peuvent avoir un impact sur la vitesse d execution du
>programme et son utilisation de la memoire.
Oui, encore que le compilo a le droit d'optimiser des copies, et
heureusement encore.
Deux trois points vraiment importants sur le sujet:
- on differencie en premier approche les objets C++ en "classes
concretes": ce sont des petits objets (point dans le plan, date) qui
vont avoir une semantique de valeur. On ne se prive pas pour en
placer directement sur la pile, ou pour en passer directement aux
fonctions. Le reste, ce sont les gros objets, souvent concus pour
l'heritage, et ceux-la seront passes par reference et possedent
souvent leur implementation 'des 4' fonctions: constructeur par
defaut, constructeur de copie, operateur d'affectation, et
destructeur. Dans beaucoup de cas modernes, on delegue: les
smart-pointer de boost permettent par exemple de ne rien avoir a
implementer de tout ca, et juste composer les champs necessaires.
- pour beaucoup d'objets, on va donc privilegier le passage de
parametres par reference. Il est alors vital d'etre
"const-correct" (bien annoter tous les parametres qui doivent etre
const d'un const), d'abord, parce que ca documente la fonction et que
ca evite les erreurs stupides (ben oui, un passage par reference, ca
permet de faire des effets de bord ignobles), mais aussi, parce que
les temporaires ne peuvent etre passes que par parametres const,
e.g., f(A(5)) ne fonctionnera que si f(const A&) et pas f(A&).
- un cas ou les references ne sont pas appropries, c'est lorsqu'au
final il faut vraiment creer, un nouveau objet, le classique etant
operator+, par exemple, qui aura souvent comme implementation (je
laisse de cote les techniques d'expression-value a la Veldhuizen):
A operator+(const A& a, const A& b)
{
A c(a);
c += b;
return c;
}
Pas le choix, faut construire l'objet, et donc faire la copie. Mais
un compilo bien foutu disposera de "return value optimisation", et
donc construira c directement en place pour eviter une copie.
Mes petits camarades completeront...
In article <20110607022317.75501bd8@daenerys.zolive.eu>,
Olivier BURELLI <olivier@burelli.fr> wrote:
>l'auteur expose la problématique des classe, en abordant
>succinctement le constructeur de copie qui sera aborde au chapitre
>suivant. le theoreme "constructeur de copie" etant ; celui -ci est
>appele a chaque fois qu'une copie temporaire de l'objet est place
>sur la pile.
>
>Lorsque cet objet temporaire est detruit a la fin de l'execution de
>la fonction, son destructeur est appelé. Si la fonction renvoie un
>objet par valeur, il faut egalement faire copie de cet objet et le
>detruire.
>
>Avec des objets volumineux ces appels de constructeurs et
>destructeurs peuvent avoir un impact sur la vitesse d execution du
>programme et son utilisation de la memoire.
Oui, encore que le compilo a le droit d'optimiser des copies, et
heureusement encore.
Deux trois points vraiment importants sur le sujet:
- on differencie en premier approche les objets C++ en "classes
concretes": ce sont des petits objets (point dans le plan, date) qui
vont avoir une semantique de valeur. On ne se prive pas pour en
placer directement sur la pile, ou pour en passer directement aux
fonctions. Le reste, ce sont les gros objets, souvent concus pour
l'heritage, et ceux-la seront passes par reference et possedent
souvent leur implementation 'des 4' fonctions: constructeur par
defaut, constructeur de copie, operateur d'affectation, et
destructeur. Dans beaucoup de cas modernes, on delegue: les
smart-pointer de boost permettent par exemple de ne rien avoir a
implementer de tout ca, et juste composer les champs necessaires.
- pour beaucoup d'objets, on va donc privilegier le passage de
parametres par reference. Il est alors vital d'etre
"const-correct" (bien annoter tous les parametres qui doivent etre
const d'un const), d'abord, parce que ca documente la fonction et que
ca evite les erreurs stupides (ben oui, un passage par reference, ca
permet de faire des effets de bord ignobles), mais aussi, parce que
les temporaires ne peuvent etre passes que par parametres const,
e.g., f(A(5)) ne fonctionnera que si f(const A&) et pas f(A&).
- un cas ou les references ne sont pas appropries, c'est lorsqu'au
final il faut vraiment creer, un nouveau objet, le classique etant
operator+, par exemple, qui aura souvent comme implementation (je
laisse de cote les techniques d'expression-value a la Veldhuizen):
A operator+(const A& a, const A& b)
{
A c(a);
c += b;
return c;
}
Pas le choix, faut construire l'objet, et donc faire la copie. Mais
un compilo bien foutu disposera de "return value optimisation", et
donc construira c directement en place pour eviter une copie.
Mes petits camarades completeront...
In article ,
Olivier BURELLI wrote:
>l'auteur expose la problématique des classe, en abordant
>succinctement le constructeur de copie qui sera aborde au chapitre
>suivant. le theoreme "constructeur de copie" etant ; celui -ci est
>appele a chaque fois qu'une copie temporaire de l'objet est place
>sur la pile.
>
>Lorsque cet objet temporaire est detruit a la fin de l'execution de
>la fonction, son destructeur est appelé. Si la fonction renvoie un
>objet par valeur, il faut egalement faire copie de cet objet et le
>detruire.
>
>Avec des objets volumineux ces appels de constructeurs et
>destructeurs peuvent avoir un impact sur la vitesse d execution du
>programme et son utilisation de la memoire.
Oui, encore que le compilo a le droit d'optimiser des copies, et
heureusement encore.
Deux trois points vraiment importants sur le sujet:
- on differencie en premier approche les objets C++ en "classes
concretes": ce sont des petits objets (point dans le plan, date) qui
vont avoir une semantique de valeur. On ne se prive pas pour en
placer directement sur la pile, ou pour en passer directement aux
fonctions. Le reste, ce sont les gros objets, souvent concus pour
l'heritage, et ceux-la seront passes par reference et possedent
souvent leur implementation 'des 4' fonctions: constructeur par
defaut, constructeur de copie, operateur d'affectation, et
destructeur. Dans beaucoup de cas modernes, on delegue: les
smart-pointer de boost permettent par exemple de ne rien avoir a
implementer de tout ca, et juste composer les champs necessaires.
- pour beaucoup d'objets, on va donc privilegier le passage de
parametres par reference. Il est alors vital d'etre
"const-correct" (bien annoter tous les parametres qui doivent etre
const d'un const), d'abord, parce que ca documente la fonction et que
ca evite les erreurs stupides (ben oui, un passage par reference, ca
permet de faire des effets de bord ignobles), mais aussi, parce que
les temporaires ne peuvent etre passes que par parametres const,
e.g., f(A(5)) ne fonctionnera que si f(const A&) et pas f(A&).
- un cas ou les references ne sont pas appropries, c'est lorsqu'au
final il faut vraiment creer, un nouveau objet, le classique etant
operator+, par exemple, qui aura souvent comme implementation (je
laisse de cote les techniques d'expression-value a la Veldhuizen):
A operator+(const A& a, const A& b)
{
A c(a);
c += b;
return c;
}
Pas le choix, faut construire l'objet, et donc faire la copie. Mais
un compilo bien foutu disposera de "return value optimisation", et
donc construira c directement en place pour eviter une copie.
Mes petits camarades completeront...
J'ai un projet personnel, écrire un programme de gestion de finance
personnelle, j'ai choisi QT que je devrai aussi étudier. A ce sujet il
faudra que je post sur fr.comp.os.bsd sur l'absence de la lib
debug sur QtCreator une foi bien compris le pb.
Challenge un peu gros, souhaitant m'appuyer sur une base postgresql. Le
pb n'étant pas là, j'ai de bonne connaissance en SQL et en architecture
de SGBDR.
La programmation reste pour moi un loisir, je prends le temps qu'il
faut.
J'ai un projet personnel, écrire un programme de gestion de finance
personnelle, j'ai choisi QT que je devrai aussi étudier. A ce sujet il
faudra que je post sur fr.comp.os.bsd sur l'absence de la lib
debug sur QtCreator une foi bien compris le pb.
Challenge un peu gros, souhaitant m'appuyer sur une base postgresql. Le
pb n'étant pas là, j'ai de bonne connaissance en SQL et en architecture
de SGBDR.
La programmation reste pour moi un loisir, je prends le temps qu'il
faut.
J'ai un projet personnel, écrire un programme de gestion de finance
personnelle, j'ai choisi QT que je devrai aussi étudier. A ce sujet il
faudra que je post sur fr.comp.os.bsd sur l'absence de la lib
debug sur QtCreator une foi bien compris le pb.
Challenge un peu gros, souhaitant m'appuyer sur une base postgresql. Le
pb n'étant pas là, j'ai de bonne connaissance en SQL et en architecture
de SGBDR.
La programmation reste pour moi un loisir, je prends le temps qu'il
faut.
Common Lisp
Common Lisp
Common Lisp
On Tue, 7 Jun 2011 10:35:15 +0000 (UTC)
(Marc Espie) wrote:In article ,
Olivier BURELLI wrote:
>le trois quart des choses exprimées est abstrait pour moi :) je tag
>précieusement ce post pour, un jour ou cela devient comprehensible je
>le retrouve. L'héritage et le polymorphysme ne sont abordé
>respectivement que dans 3 et 5 chapitres.
>
>J'en ai compris le principe, cela ressemble a la fin de mon
>chapitre...
Bon, ben j'ai encore plus envie de te dire de jeter ton bouquin aux
orties. Les exemples te montrent un constructeur de copie, te parlent
de passage par reference, alors qu'ils n'ont pas aborde les points
dont je parle (specifiquement, les 4 methodes qui vont ensemble). Et
ca parle de pointeur.
Desole, mais ca ressemble fort a un bouquin de C++ ecrit par
quelqu'un qui a fait beaucoup de C et qui ne pense pas en C++.
Un vrai bon bouquin de C++ ne va pas presenter les choses dans le meme
ordre.
Je l'avais justement achete car ce livre était plébiscité pour son
approche C++ pur. Il n'y ait effectivement fait aucune allusion a
une syntaxique ou une approche du C.
Je comprends l'argumentation, je suis l'élève dans ce cas de figure ne
peux remettre en question le jugement du professeur (mon livre).
Néanmoins, si tu peux me conseiller un livre je suis preneur, toi qui
enseigne si je ne me trompe pas.
On Tue, 7 Jun 2011 10:35:15 +0000 (UTC)
espie@lain.home (Marc Espie) wrote:
In article <20110607120708.672d6ff0@daenerys.zolive.eu>,
Olivier BURELLI <olivier@burelli.fr> wrote:
>le trois quart des choses exprimées est abstrait pour moi :) je tag
>précieusement ce post pour, un jour ou cela devient comprehensible je
>le retrouve. L'héritage et le polymorphysme ne sont abordé
>respectivement que dans 3 et 5 chapitres.
>
>J'en ai compris le principe, cela ressemble a la fin de mon
>chapitre...
Bon, ben j'ai encore plus envie de te dire de jeter ton bouquin aux
orties. Les exemples te montrent un constructeur de copie, te parlent
de passage par reference, alors qu'ils n'ont pas aborde les points
dont je parle (specifiquement, les 4 methodes qui vont ensemble). Et
ca parle de pointeur.
Desole, mais ca ressemble fort a un bouquin de C++ ecrit par
quelqu'un qui a fait beaucoup de C et qui ne pense pas en C++.
Un vrai bon bouquin de C++ ne va pas presenter les choses dans le meme
ordre.
Je l'avais justement achete car ce livre était plébiscité pour son
approche C++ pur. Il n'y ait effectivement fait aucune allusion a
une syntaxique ou une approche du C.
Je comprends l'argumentation, je suis l'élève dans ce cas de figure ne
peux remettre en question le jugement du professeur (mon livre).
Néanmoins, si tu peux me conseiller un livre je suis preneur, toi qui
enseigne si je ne me trompe pas.
On Tue, 7 Jun 2011 10:35:15 +0000 (UTC)
(Marc Espie) wrote:In article ,
Olivier BURELLI wrote:
>le trois quart des choses exprimées est abstrait pour moi :) je tag
>précieusement ce post pour, un jour ou cela devient comprehensible je
>le retrouve. L'héritage et le polymorphysme ne sont abordé
>respectivement que dans 3 et 5 chapitres.
>
>J'en ai compris le principe, cela ressemble a la fin de mon
>chapitre...
Bon, ben j'ai encore plus envie de te dire de jeter ton bouquin aux
orties. Les exemples te montrent un constructeur de copie, te parlent
de passage par reference, alors qu'ils n'ont pas aborde les points
dont je parle (specifiquement, les 4 methodes qui vont ensemble). Et
ca parle de pointeur.
Desole, mais ca ressemble fort a un bouquin de C++ ecrit par
quelqu'un qui a fait beaucoup de C et qui ne pense pas en C++.
Un vrai bon bouquin de C++ ne va pas presenter les choses dans le meme
ordre.
Je l'avais justement achete car ce livre était plébiscité pour son
approche C++ pur. Il n'y ait effectivement fait aucune allusion a
une syntaxique ou une approche du C.
Je comprends l'argumentation, je suis l'élève dans ce cas de figure ne
peux remettre en question le jugement du professeur (mon livre).
Néanmoins, si tu peux me conseiller un livre je suis preneur, toi qui
enseigne si je ne me trompe pas.