"Loïc Joly" a écrit dans le message news: 41a3986a$0$17392$
Gabriel Dos Reis wrote:
[...]
James a raison
[...]
Ce jour est à marquer d'une croix dans le calendrier ;)
ambigu : la croix, c'est pour "... a..." ou pour "... wrote" ? ;-)
Le "... wrote"
Pour le "...a...", je n'ose me prononcer ni dans un sens, ni dans l'autre...
-- Loïc
Anthony Fleury
Gabriel Dos Reis wrote:
Andre Heinen writes:
| Il est garanti qu'une référence "pointe" toujours sur quelque | chose.
int& f() { int i = 0; return i; }
int main() { int& r = f(); return r; }
Bonsoir, petite question pour ma culture : Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit par la norme, pourquoi ? Est-ce comme certaines choses, pour ne pas ajouter trop de boulot aux concepteurs de compilateurs ? car tout compilateur actuelle le détecte et envoie un warning. (et je ne vois de toute facon pas comment un compilateur pourrait ne pas le detecter, vu qu'il doit détruire tout objet local avant la sortie de la fonction et dans l'ordre inverse de leur création). Ou alors il y a un cas qui m'échappe et qui fait que cette règle ne doit pas être mise dans la norme ?!
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Gabriel Dos Reis wrote:
Andre Heinen <nospam@nospam.invalid> writes:
| Il est garanti qu'une référence "pointe" toujours sur quelque
| chose.
int& f() { int i = 0; return i; }
int main() { int& r = f(); return r; }
Bonsoir, petite question pour ma culture :
Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit par
la norme, pourquoi ? Est-ce comme certaines choses, pour ne pas ajouter
trop de boulot aux concepteurs de compilateurs ? car tout compilateur
actuelle le détecte et envoie un warning. (et je ne vois de toute facon pas
comment un compilateur pourrait ne pas le detecter, vu qu'il doit détruire
tout objet local avant la sortie de la fonction et dans l'ordre inverse de
leur création). Ou alors il y a un cas qui m'échappe et qui fait que cette
règle ne doit pas être mise dans la norme ?!
Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
| Il est garanti qu'une référence "pointe" toujours sur quelque | chose.
int& f() { int i = 0; return i; }
int main() { int& r = f(); return r; }
Bonsoir, petite question pour ma culture : Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit par la norme, pourquoi ? Est-ce comme certaines choses, pour ne pas ajouter trop de boulot aux concepteurs de compilateurs ? car tout compilateur actuelle le détecte et envoie un warning. (et je ne vois de toute facon pas comment un compilateur pourrait ne pas le detecter, vu qu'il doit détruire tout objet local avant la sortie de la fonction et dans l'ordre inverse de leur création). Ou alors il y a un cas qui m'échappe et qui fait que cette règle ne doit pas être mise dans la norme ?!
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Gabriel Dos Reis
Anthony Fleury writes:
| Gabriel Dos Reis wrote: | | > Andre Heinen writes: | > | > | Il est garanti qu'une référence "pointe" toujours sur quelque | > | chose. | > | > int& f() { int i = 0; return i; } | > | > int main() { int& r = f(); return r; } | | Bonsoir, petite question pour ma culture : | Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit par | la norme, pourquoi ?
Il n'est pas ill-formed, il est « undefined behaviour ».
| Est-ce comme certaines choses, pour ne pas ajouter | trop de boulot aux concepteurs de compilateurs ?
Oui. Ou plus exactement, pour ne pas demander au auteurs de compilateurs de résoudre « le problème d'arrêt ».
| car tout compilateur | actuelle le détecte et envoie un warning.
Oui, mais cet exemple est très simplissime.
| (et je ne vois de toute facon pas | comment un compilateur pourrait ne pas le detecter, vu qu'il doit détruire | tout objet local avant la sortie de la fonction et dans l'ordre inverse de | leur création). Ou alors il y a un cas qui m'échappe et qui fait que cette | règle ne doit pas être mise dans la norme ?!
Comment proposes-tu que le compilateur gère le programme main.C + alloc.C ?
Anthony Fleury <fleury_anthony@_hotmail.com_> writes:
| Gabriel Dos Reis wrote:
|
| > Andre Heinen <nospam@nospam.invalid> writes:
| >
| > | Il est garanti qu'une référence "pointe" toujours sur quelque
| > | chose.
| >
| > int& f() { int i = 0; return i; }
| >
| > int main() { int& r = f(); return r; }
|
| Bonsoir, petite question pour ma culture :
| Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit par
| la norme, pourquoi ?
Il n'est pas ill-formed, il est « undefined behaviour ».
| Est-ce comme certaines choses, pour ne pas ajouter
| trop de boulot aux concepteurs de compilateurs ?
Oui. Ou plus exactement, pour ne pas demander au auteurs de
compilateurs de résoudre « le problème d'arrêt ».
| car tout compilateur
| actuelle le détecte et envoie un warning.
Oui, mais cet exemple est très simplissime.
| (et je ne vois de toute facon pas
| comment un compilateur pourrait ne pas le detecter, vu qu'il doit détruire
| tout objet local avant la sortie de la fonction et dans l'ordre inverse de
| leur création). Ou alors il y a un cas qui m'échappe et qui fait que cette
| règle ne doit pas être mise dans la norme ?!
Comment proposes-tu que le compilateur gère le programme main.C + alloc.C ?
| Gabriel Dos Reis wrote: | | > Andre Heinen writes: | > | > | Il est garanti qu'une référence "pointe" toujours sur quelque | > | chose. | > | > int& f() { int i = 0; return i; } | > | > int main() { int& r = f(); return r; } | | Bonsoir, petite question pour ma culture : | Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit par | la norme, pourquoi ?
Il n'est pas ill-formed, il est « undefined behaviour ».
| Est-ce comme certaines choses, pour ne pas ajouter | trop de boulot aux concepteurs de compilateurs ?
Oui. Ou plus exactement, pour ne pas demander au auteurs de compilateurs de résoudre « le problème d'arrêt ».
| car tout compilateur | actuelle le détecte et envoie un warning.
Oui, mais cet exemple est très simplissime.
| (et je ne vois de toute facon pas | comment un compilateur pourrait ne pas le detecter, vu qu'il doit détruire | tout objet local avant la sortie de la fonction et dans l'ordre inverse de | leur création). Ou alors il y a un cas qui m'échappe et qui fait que cette | règle ne doit pas être mise dans la norme ?!
Comment proposes-tu que le compilateur gère le programme main.C + alloc.C ?
| Gabriel Dos Reis wrote: | > int main() { int& r = f(); return r; } | | Bonsoir, petite question pour ma culture : | Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit | par la norme, pourquoi ?
Il n'est pas ill-formed, il est « undefined behaviour ».
En fait, ce que je voulais dire (en réagissant trop vite) c'est qu'il devrait être ill-formed. Mais à ce tarif là, on enlève tous les UBs...
| Est-ce comme certaines choses, pour ne pas ajouter | trop de boulot aux concepteurs de compilateurs ? Oui. Ou plus exactement, pour ne pas demander au auteurs de compilateurs de résoudre « le problème d'arrêt ». | car tout compilateur | actuelle le détecte et envoie un warning. Oui, mais cet exemple est très simplissime.
Oui, et le but de ma question était de voir justement des exemples un peu moins simples et qui bloqueraient. Merci ! En fait, je n'ai pas assez l'habitude du C++ je pense car je ne trouve jamais ce type d'exemples comme ca d'un coup ! Et surtout je me limitais à mon souvenir dans mes premiers temps de C++ où je renvoyais ce genre de références et que le compilo me le détectait déjà.
| (et je ne vois de toute facon pas | comment un compilateur pourrait ne pas le detecter, vu qu'il doit | détruire tout objet local avant la sortie de la fonction et dans l'ordre | inverse de leur création). Ou alors il y a un cas qui m'échappe et qui | fait que cette règle ne doit pas être mise dans la norme ?! Comment proposes-tu que le compilateur gère le programme main.C + alloc.C ? // main.C int* alloc(int&); int& f() { int r = 3; return *alloc(r); } int main() { int& r = f(); return r; } // alloc.C int* alloc(int& x) { x = 0; return &x; }
Je ne sais pas si ca serait viable (je suis pas un pro en compilation loin de là) mais l'idée qui me viendrait à l'esprit, serait de décorer les noms de variables, pour savoir exactement leur type et leur portée. Sur le papier ca « fonctionne » (avec mes maigres connaissances en compilateurs), enfin ca a l'air de permettre de détecter des cas moins simples en permettant de suivre toutes les variables, mais à mon avis ca complique beaucoup le boulot du compilateur, et ca rendrait la compilation fortement plus longue. Enfin c'est qu'une idée, je ne sais pas si c'est vraiment faisable/utilisable :-) (et ca mettrait des incompatibilités avec le C où certains cas qui seraient refusés - car ca marche pareil pour les pointeurs - sont des UBs en C)
Anthonysalut -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Gabriel Dos Reis wrote:
Anthony Fleury <fleury_anthony@_hotmail.com_> writes:
| Gabriel Dos Reis wrote:
| > int main() { int& r = f(); return r; }
|
| Bonsoir, petite question pour ma culture :
| Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit
| par la norme, pourquoi ?
Il n'est pas ill-formed, il est « undefined behaviour ».
En fait, ce que je voulais dire (en réagissant trop vite) c'est qu'il
devrait être ill-formed. Mais à ce tarif là, on enlève tous les UBs...
| Est-ce comme certaines choses, pour ne pas ajouter
| trop de boulot aux concepteurs de compilateurs ?
Oui. Ou plus exactement, pour ne pas demander au auteurs de
compilateurs de résoudre « le problème d'arrêt ».
| car tout compilateur
| actuelle le détecte et envoie un warning.
Oui, mais cet exemple est très simplissime.
Oui, et le but de ma question était de voir justement des exemples un peu
moins simples et qui bloqueraient. Merci ! En fait, je n'ai pas assez
l'habitude du C++ je pense car je ne trouve jamais ce type d'exemples comme
ca d'un coup ! Et surtout je me limitais à mon souvenir dans mes premiers
temps de C++ où je renvoyais ce genre de références et que le compilo me le
détectait déjà.
| (et je ne vois de toute facon pas
| comment un compilateur pourrait ne pas le detecter, vu qu'il doit
| détruire tout objet local avant la sortie de la fonction et dans l'ordre
| inverse de leur création). Ou alors il y a un cas qui m'échappe et qui
| fait que cette règle ne doit pas être mise dans la norme ?!
Comment proposes-tu que le compilateur gère le programme main.C + alloc.C
?
// main.C
int* alloc(int&);
int& f() { int r = 3; return *alloc(r); }
int main() { int& r = f(); return r; }
// alloc.C
int* alloc(int& x) { x = 0; return &x; }
Je ne sais pas si ca serait viable (je suis pas un pro en compilation loin
de là) mais l'idée qui me viendrait à l'esprit, serait de décorer les noms
de variables, pour savoir exactement leur type et leur portée. Sur le
papier ca « fonctionne » (avec mes maigres connaissances en compilateurs),
enfin ca a l'air de permettre de détecter des cas moins simples en
permettant de suivre toutes les variables, mais à mon avis ca complique
beaucoup le boulot du compilateur, et ca rendrait la compilation fortement
plus longue. Enfin c'est qu'une idée, je ne sais pas si c'est vraiment
faisable/utilisable :-) (et ca mettrait des incompatibilités avec le C où
certains cas qui seraient refusés - car ca marche pareil pour les pointeurs
- sont des UBs en C)
Anthonysalut
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
| Gabriel Dos Reis wrote: | > int main() { int& r = f(); return r; } | | Bonsoir, petite question pour ma culture : | Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit | par la norme, pourquoi ?
Il n'est pas ill-formed, il est « undefined behaviour ».
En fait, ce que je voulais dire (en réagissant trop vite) c'est qu'il devrait être ill-formed. Mais à ce tarif là, on enlève tous les UBs...
| Est-ce comme certaines choses, pour ne pas ajouter | trop de boulot aux concepteurs de compilateurs ? Oui. Ou plus exactement, pour ne pas demander au auteurs de compilateurs de résoudre « le problème d'arrêt ». | car tout compilateur | actuelle le détecte et envoie un warning. Oui, mais cet exemple est très simplissime.
Oui, et le but de ma question était de voir justement des exemples un peu moins simples et qui bloqueraient. Merci ! En fait, je n'ai pas assez l'habitude du C++ je pense car je ne trouve jamais ce type d'exemples comme ca d'un coup ! Et surtout je me limitais à mon souvenir dans mes premiers temps de C++ où je renvoyais ce genre de références et que le compilo me le détectait déjà.
| (et je ne vois de toute facon pas | comment un compilateur pourrait ne pas le detecter, vu qu'il doit | détruire tout objet local avant la sortie de la fonction et dans l'ordre | inverse de leur création). Ou alors il y a un cas qui m'échappe et qui | fait que cette règle ne doit pas être mise dans la norme ?! Comment proposes-tu que le compilateur gère le programme main.C + alloc.C ? // main.C int* alloc(int&); int& f() { int r = 3; return *alloc(r); } int main() { int& r = f(); return r; } // alloc.C int* alloc(int& x) { x = 0; return &x; }
Je ne sais pas si ca serait viable (je suis pas un pro en compilation loin de là) mais l'idée qui me viendrait à l'esprit, serait de décorer les noms de variables, pour savoir exactement leur type et leur portée. Sur le papier ca « fonctionne » (avec mes maigres connaissances en compilateurs), enfin ca a l'air de permettre de détecter des cas moins simples en permettant de suivre toutes les variables, mais à mon avis ca complique beaucoup le boulot du compilateur, et ca rendrait la compilation fortement plus longue. Enfin c'est qu'une idée, je ne sais pas si c'est vraiment faisable/utilisable :-) (et ca mettrait des incompatibilités avec le C où certains cas qui seraient refusés - car ca marche pareil pour les pointeurs - sont des UBs en C)
Anthonysalut -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Gabriel Dos Reis
Anthony Fleury writes:
| Gabriel Dos Reis wrote: | | > Anthony Fleury writes: | > | > | Gabriel Dos Reis wrote: | > | > int main() { int& r = f(); return r; } | > | | > | Bonsoir, petite question pour ma culture : | > | Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit | > | par la norme, pourquoi ? | > | > Il n'est pas ill-formed, il est « undefined behaviour ». | | En fait, ce que je voulais dire (en réagissant trop vite) c'est qu'il | devrait être ill-formed. Mais à ce tarif là, on enlève tous les UBs...
ça serait drôlement bien ça ; mais je ne suis pas fanatique jusqu'à ce point :-)
-- Gaby
Anthony Fleury <fleury_anthony@_hotmail.com_> writes:
| Gabriel Dos Reis wrote:
|
| > Anthony Fleury <fleury_anthony@_hotmail.com_> writes:
| >
| > | Gabriel Dos Reis wrote:
| > | > int main() { int& r = f(); return r; }
| > |
| > | Bonsoir, petite question pour ma culture :
| > | Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit
| > | par la norme, pourquoi ?
| >
| > Il n'est pas ill-formed, il est « undefined behaviour ».
|
| En fait, ce que je voulais dire (en réagissant trop vite) c'est qu'il
| devrait être ill-formed. Mais à ce tarif là, on enlève tous les UBs...
ça serait drôlement bien ça ; mais je ne suis pas fanatique jusqu'à ce
point :-)
| Gabriel Dos Reis wrote: | | > Anthony Fleury writes: | > | > | Gabriel Dos Reis wrote: | > | > int main() { int& r = f(); return r; } | > | | > | Bonsoir, petite question pour ma culture : | > | Ce code est pour moi « ill-formed » mais cependant il n'est pas interdit | > | par la norme, pourquoi ? | > | > Il n'est pas ill-formed, il est « undefined behaviour ». | | En fait, ce que je voulais dire (en réagissant trop vite) c'est qu'il | devrait être ill-formed. Mais à ce tarif là, on enlève tous les UBs...
ça serait drôlement bien ça ; mais je ne suis pas fanatique jusqu'à ce point :-)
