Bien sur, le code étant légèrement plus subtile que ca, mais en gros c'était
ca... Evidemment ca ne peut pas marcher, on passe en paramètre de foo() une
reférence sur un objet encore non construit, puisque le résultat de foo est
justement le paramètre du constructeur de r...
Ce qui m'étonne, c'est qu'aucun des compilateurs avec lequels j'ai testé ce
code (VC++, gcc, HP-UX aCC) n'a emis la moindre erreur ou warning. Ce qui
m'étonne d'autant plus de la part de VC++ qui est légèrement paranoïaque
question warning a mon goût... Alors pourquoi ce silence ? Je n'ai pas
l'impression que le cas soit particulièrement complexe à détecter, cela
signifirait-il que bien que buggé, le code soit valide vis-à-vis de la norme
?
Bien sur, le code étant légèrement plus subtile que ca, mais en gros c'était
ca... Evidemment ca ne peut pas marcher, on passe en paramètre de foo() une
reférence sur un objet encore non construit, puisque le résultat de foo est
justement le paramètre du constructeur de r...
Pour moi ce n'est pas tout a fait ca : foo n'est pas le paramètre du constructeur de r. la ligne "std::string r = foo(r);" est plutot équivalente à "std::string r; r = foo(r);"
Ce dont je ne suis pas sur, c'est si ta ligne a un comportement défini ou non.
"GOURUL Frédéric" <fgourul.nospam@9online.fr> a écrit dans le message de
news:ce8qbi$bpd$1@apollon.grec.isp.9tel.net...
Bonjour à tous,
Après avoir passé un peu de temps à la recherche de ce bug, je m'interroge
sur le mutisme de mon compilateur.
Bien sur, le code étant légèrement plus subtile que ca, mais en gros
c'était
ca... Evidemment ca ne peut pas marcher, on passe en paramètre de foo()
une
reférence sur un objet encore non construit, puisque le résultat de foo
est
justement le paramètre du constructeur de r...
Pour moi ce n'est pas tout a fait ca :
foo n'est pas le paramètre du constructeur de r.
la ligne "std::string r = foo(r);" est plutot équivalente à "std::string r;
r = foo(r);"
Ce dont je ne suis pas sur, c'est si ta ligne a un comportement défini ou
non.
Bien sur, le code étant légèrement plus subtile que ca, mais en gros c'était
ca... Evidemment ca ne peut pas marcher, on passe en paramètre de foo() une
reférence sur un objet encore non construit, puisque le résultat de foo est
justement le paramètre du constructeur de r...
Pour moi ce n'est pas tout a fait ca : foo n'est pas le paramètre du constructeur de r. la ligne "std::string r = foo(r);" est plutot équivalente à "std::string r; r = foo(r);"
Ce dont je ne suis pas sur, c'est si ta ligne a un comportement défini ou non.
GOURUL Frédéric
"Nico" a écrit dans le message de news:41080270$0$306$
Pour moi ce n'est pas tout a fait ca : foo n'est pas le paramètre du constructeur de r. la ligne "std::string r = foo(r);" est plutot équivalente à "std::string r;
r = foo(r);"
Non, ici c'est bien le constructeur de std::string qui est appelé avec comme paramètre le résultat de foo(). La notation est un peu trompeuse et lorsque je l'ai écrit, j'ai pensé, sans y réfléchir, que c'était l'operateur d'affectation qui était appelé, alors que ce n'est pas le cas...
Ce dont je ne suis pas sur, c'est si ta ligne a un comportement défini ou non.
pour moi, c'est bien un comportement indéfini. En tout cas, sur les trois compilateurs testés et assure d'ailleurs un plantage assez rapide...
"Nico" <nvervell@club-internet.fr> a écrit dans le message de
news:41080270$0$306$7a628cd7@news.club-internet.fr...
Pour moi ce n'est pas tout a fait ca :
foo n'est pas le paramètre du constructeur de r.
la ligne "std::string r = foo(r);" est plutot équivalente à "std::string
r;
r = foo(r);"
Non, ici c'est bien le constructeur de std::string qui est appelé avec comme
paramètre le résultat de foo(). La notation est un peu trompeuse et lorsque
je l'ai écrit, j'ai pensé, sans y réfléchir, que c'était l'operateur
d'affectation qui était appelé, alors que ce n'est pas le cas...
Ce dont je ne suis pas sur, c'est si ta ligne a un comportement défini ou
non.
pour moi, c'est bien un comportement indéfini. En tout cas, sur les trois
compilateurs testés et assure d'ailleurs un plantage assez rapide...
"Nico" a écrit dans le message de news:41080270$0$306$
Pour moi ce n'est pas tout a fait ca : foo n'est pas le paramètre du constructeur de r. la ligne "std::string r = foo(r);" est plutot équivalente à "std::string r;
r = foo(r);"
Non, ici c'est bien le constructeur de std::string qui est appelé avec comme paramètre le résultat de foo(). La notation est un peu trompeuse et lorsque je l'ai écrit, j'ai pensé, sans y réfléchir, que c'était l'operateur d'affectation qui était appelé, alors que ce n'est pas le cas...
Ce dont je ne suis pas sur, c'est si ta ligne a un comportement défini ou non.
pour moi, c'est bien un comportement indéfini. En tout cas, sur les trois compilateurs testés et assure d'ailleurs un plantage assez rapide...
Loïc Joly
GOURUL Frédéric wrote:
Bonjour à tous,
Après avoir passé un peu de temps à la recherche de ce bug, je m'interroge sur le mutisme de mon compilateur.
Bien sur, le code étant légèrement plus subtile que ca, mais en gros c'était ca... Evidemment ca ne peut pas marcher, on passe en paramètre de foo() une reférence sur un objet encore non construit, puisque le résultat de foo est justement le paramètre du constructeur de r...
Ce qui m'étonne, c'est qu'aucun des compilateurs avec lequels j'ai testé ce code (VC++, gcc, HP-UX aCC) n'a emis la moindre erreur ou warning. Ce qui m'étonne d'autant plus de la part de VC++ qui est légèrement paranoïaque question warning a mon goût... Alors pourquoi ce silence ? Je n'ai pas l'impression que le cas soit particulièrement complexe à détecter, cela signifirait-il que bien que buggé, le code soit valide vis-à-vis de la norme ?
Non. Le code n'est pas valide parce que son conportement est indéfini.
Mais la norme n'interdit pas au compilateur de compiler du code dont la syntaxe est légale et dont le comportement est indéfini.
La norme est explicite: Le compilateur n'est pas obligé de découvrir des erreurs sémantiques dans des cas où la norme dit "no diagnostic required" ou bien "le comportement est indéfini". Il n'est donc obligé que de découvrir des erreurs sémantiques que la norme marque explicitement comme "diagnosable" - et ce n'est pas le cas ici.
Bien sur, le code étant légèrement plus subtile que ca, mais en gros c'était
ca... Evidemment ca ne peut pas marcher, on passe en paramètre de foo() une
reférence sur un objet encore non construit, puisque le résultat de foo est
justement le paramètre du constructeur de r...
Ce qui m'étonne, c'est qu'aucun des compilateurs avec lequels j'ai testé ce
code (VC++, gcc, HP-UX aCC) n'a emis la moindre erreur ou warning. Ce qui
m'étonne d'autant plus de la part de VC++ qui est légèrement paranoïaque
question warning a mon goût... Alors pourquoi ce silence ? Je n'ai pas
l'impression que le cas soit particulièrement complexe à détecter, cela
signifirait-il que bien que buggé, le code soit valide vis-à-vis de la norme
?
Non. Le code n'est pas valide parce que son conportement est indéfini.
Mais la norme n'interdit pas au compilateur de compiler du code dont
la syntaxe est légale et dont le comportement est indéfini.
La norme est explicite: Le compilateur n'est pas obligé de découvrir
des erreurs sémantiques dans des cas où la norme dit "no diagnostic
required" ou bien "le comportement est indéfini". Il n'est donc obligé
que de découvrir des erreurs sémantiques que la norme marque
explicitement comme "diagnosable" - et ce n'est pas le cas ici.
Bien sur, le code étant légèrement plus subtile que ca, mais en gros c'était ca... Evidemment ca ne peut pas marcher, on passe en paramètre de foo() une reférence sur un objet encore non construit, puisque le résultat de foo est justement le paramètre du constructeur de r...
Ce qui m'étonne, c'est qu'aucun des compilateurs avec lequels j'ai testé ce code (VC++, gcc, HP-UX aCC) n'a emis la moindre erreur ou warning. Ce qui m'étonne d'autant plus de la part de VC++ qui est légèrement paranoïaque question warning a mon goût... Alors pourquoi ce silence ? Je n'ai pas l'impression que le cas soit particulièrement complexe à détecter, cela signifirait-il que bien que buggé, le code soit valide vis-à-vis de la norme ?
Non. Le code n'est pas valide parce que son conportement est indéfini.
Mais la norme n'interdit pas au compilateur de compiler du code dont la syntaxe est légale et dont le comportement est indéfini.
La norme est explicite: Le compilateur n'est pas obligé de découvrir des erreurs sémantiques dans des cas où la norme dit "no diagnostic required" ou bien "le comportement est indéfini". Il n'est donc obligé que de découvrir des erreurs sémantiques que la norme marque explicitement comme "diagnosable" - et ce n'est pas le cas ici.
