Il y a aussi que tu peux écrire un volatile sig_atomic_t dans un handler de signal.
Exact.
Il y a surout que les accès à un objet volatile font partie du comportement visible de ton programme. Bien que là, évidemment, ce qu'on entend par « accès » est laissé à l'implémentation -- beaucoup de compilateurs se contentent à le définir comme l'exécution d'une instruction de load ou de store, alors que nous savons qu'avec les pipelines d'un processeur moderne, c'est loin de suffire.
Pour le reste, c'est tres vague. C'est quoi une optimisation agressive? Est-ce que deplacer une lecture avant ou une ecriture apres un acces a une variable volatile en est une? Ca gene l'utilisation de
variables volatile comme synchronisation. Est-ce qu'acceder a une valeur en cache en est une? Sur certaines architectures multi-processeurs, il faut synchroniser explicitement les caches. Ces deux choses ne sont generalement pas traitees par volatile tel qu'implemente par la plupart des compilateurs (en fait je n'en connais pas qui les traite).
La norme est assez clair que l'accès à un objet volatile doit avoir lieu avant le point de séquencement suivant.
Oui, mais il y a la regle du as-if. Les compilateurs deplacent tout le temps des choses au-dela des points de sequencement avec cette regle vu la formulation ("agressive optimisation involving the [volatile] object") je ne crois pas que ce soit interdit. Le deplacement ne concerne pas l'objet volatile.
En ce qui concerne la synchronisation, je crois que c'est assez clair aussi que le comportement particulier des objets volatile ne concerne que les objets volatile, c-à-d que le compilateur est libre à déplacer les autres accès comme il veut, dans la mésure que ça ne change pas ce qu'on écrit à un volatile ou qu'on écrit vers une sortie (FILE* ou streambuf).
Donc tu es d'accord.
En ce qui concerne les architectures multi-processeur, c'est à mon avis assez clair ce que la norme *veut*, c-à-d l'intention. C'est que si j'écris dans un objet volatile sur un processeur, le résultat de cette écriture soit immédiatement visible aux lectures à travers un volatile sur un autre processeur (qu'il s'agit des threads, ou de la mémoire partagée et deux processus). Mais la norme ne l'exige pas, même si c'est l'intention, et dans la pratique, les compilateurs Sparc (les seuls que je connais à cet égard) ne l'implémentent pas. En plus, Posix fournit d'autres méthodes de synchronisation, et ne supporte pas non plus l'utilisation de volatile ici.
Chaque fois que j'ai regarde le code genere, les caches n'etaient pas gere.
[...]
Avec les threads Posix. Probablement avec les threads Windows aussi. Mais on peut bien imaginer des modèles de thread où son utilisation aurait un sens.
J'ai l'impression que plus le temps passe, moins on a de garantie et je ne vois pas de renversement de tendance.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze@gabi-soft.fr writes:
Il y a aussi que tu peux écrire un volatile sig_atomic_t dans un handler de
signal.
Exact.
Il y a surout que les accès à un objet volatile font partie du comportement
visible de ton programme. Bien que là, évidemment, ce qu'on entend par «
accès » est laissé à l'implémentation -- beaucoup de compilateurs se
contentent à le définir comme l'exécution d'une instruction de load ou de
store, alors que nous savons qu'avec les pipelines d'un processeur moderne,
c'est loin de suffire.
Pour le reste, c'est tres vague. C'est quoi une optimisation agressive?
Est-ce que deplacer une lecture avant ou une ecriture
apres un acces a une variable volatile en est une? Ca gene l'utilisation de
variables volatile comme synchronisation. Est-ce qu'acceder a une valeur
en cache en est une? Sur certaines architectures multi-processeurs, il
faut synchroniser explicitement les caches. Ces deux choses ne sont
generalement pas traitees par volatile tel qu'implemente par la plupart
des compilateurs (en fait je n'en
connais pas qui les traite).
La norme est assez clair que l'accès à un objet volatile doit avoir
lieu avant le point de séquencement suivant.
Oui, mais il y a la regle du as-if. Les compilateurs deplacent tout
le temps des choses au-dela des points de sequencement avec cette
regle vu la formulation ("agressive optimisation involving the
[volatile] object") je ne crois pas que ce soit interdit. Le
deplacement ne concerne pas l'objet volatile.
En ce qui concerne la synchronisation, je crois que c'est assez
clair aussi que le comportement particulier des objets volatile ne
concerne que les objets volatile, c-à-d que le compilateur est libre
à déplacer les autres accès comme il veut, dans la mésure que ça ne
change pas ce qu'on écrit à un volatile ou qu'on écrit vers une
sortie (FILE* ou streambuf).
Donc tu es d'accord.
En ce qui concerne les architectures multi-processeur, c'est à mon avis
assez clair ce que la norme *veut*, c-à-d l'intention. C'est que si j'écris
dans un objet volatile sur un processeur, le résultat de cette écriture
soit immédiatement visible aux lectures à travers un volatile sur un autre
processeur (qu'il s'agit des threads, ou de la mémoire partagée et deux
processus). Mais la norme ne l'exige pas, même si c'est l'intention, et
dans la pratique, les compilateurs Sparc (les seuls que je connais à cet
égard) ne l'implémentent pas. En plus, Posix fournit d'autres méthodes de
synchronisation, et ne supporte pas non plus l'utilisation de volatile ici.
Chaque fois que j'ai regarde le code genere, les caches n'etaient pas
gere.
[...]
Avec les threads Posix. Probablement avec les threads Windows aussi.
Mais on peut bien imaginer des modèles de thread où son utilisation
aurait un sens.
J'ai l'impression que plus le temps passe, moins on a de garantie et
je ne vois pas de renversement de tendance.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Il y a aussi que tu peux écrire un volatile sig_atomic_t dans un handler de signal.
Exact.
Il y a surout que les accès à un objet volatile font partie du comportement visible de ton programme. Bien que là, évidemment, ce qu'on entend par « accès » est laissé à l'implémentation -- beaucoup de compilateurs se contentent à le définir comme l'exécution d'une instruction de load ou de store, alors que nous savons qu'avec les pipelines d'un processeur moderne, c'est loin de suffire.
Pour le reste, c'est tres vague. C'est quoi une optimisation agressive? Est-ce que deplacer une lecture avant ou une ecriture apres un acces a une variable volatile en est une? Ca gene l'utilisation de
variables volatile comme synchronisation. Est-ce qu'acceder a une valeur en cache en est une? Sur certaines architectures multi-processeurs, il faut synchroniser explicitement les caches. Ces deux choses ne sont generalement pas traitees par volatile tel qu'implemente par la plupart des compilateurs (en fait je n'en connais pas qui les traite).
La norme est assez clair que l'accès à un objet volatile doit avoir lieu avant le point de séquencement suivant.
Oui, mais il y a la regle du as-if. Les compilateurs deplacent tout le temps des choses au-dela des points de sequencement avec cette regle vu la formulation ("agressive optimisation involving the [volatile] object") je ne crois pas que ce soit interdit. Le deplacement ne concerne pas l'objet volatile.
En ce qui concerne la synchronisation, je crois que c'est assez clair aussi que le comportement particulier des objets volatile ne concerne que les objets volatile, c-à-d que le compilateur est libre à déplacer les autres accès comme il veut, dans la mésure que ça ne change pas ce qu'on écrit à un volatile ou qu'on écrit vers une sortie (FILE* ou streambuf).
Donc tu es d'accord.
En ce qui concerne les architectures multi-processeur, c'est à mon avis assez clair ce que la norme *veut*, c-à-d l'intention. C'est que si j'écris dans un objet volatile sur un processeur, le résultat de cette écriture soit immédiatement visible aux lectures à travers un volatile sur un autre processeur (qu'il s'agit des threads, ou de la mémoire partagée et deux processus). Mais la norme ne l'exige pas, même si c'est l'intention, et dans la pratique, les compilateurs Sparc (les seuls que je connais à cet égard) ne l'implémentent pas. En plus, Posix fournit d'autres méthodes de synchronisation, et ne supporte pas non plus l'utilisation de volatile ici.
Chaque fois que j'ai regarde le code genere, les caches n'etaient pas gere.
[...]
Avec les threads Posix. Probablement avec les threads Windows aussi. Mais on peut bien imaginer des modèles de thread où son utilisation aurait un sens.
J'ai l'impression que plus le temps passe, moins on a de garantie et je ne vois pas de renversement de tendance.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gabriel Dos Reis
writes:
[...]
| La norme est assez clair que l'accès à un objet volatile doit avoir | lieu | avant le point de séquencement suivant.
et elle est aussi assez claire sur le fait que l'objet peut être modifié de manière inconnue du compilateur ou tout ce que tu veux. Un load ou store supplémentaire -- à l'insu de son plein gré -- devient alors tout à fait valide, de même qu'un load ou ou store en moins. Bref.
| En ce qui concerne la synchronisation, je crois que c'est assez clair | aussi que le comportement particulier des objets volatile ne concerne | que les objets volatile, c-à-d que le compilateur est libre à | déplacer | les autres accès comme il veut, dans la mésure que ça ne change pas | ce | qu'on écrit à un volatile ou qu'on écrit vers une sortie (FILE* ou | streambuf).
Et pourtant, ce n'est pas ce qu'elle dit -- et de fait l'écriture dans un objet volatile peut changer complètement le reste du fonctionnement du programme, y compris les valeurs des objets non volatiles.
La restriction que "volatile" n'affecte que les objets volatiles est un changement fondamental, qui n'est pas du tout dans la spécification actuelle. Il y a de l'abus dans ton « c'est assez clair ».
-- Gaby
kanze@gabi-soft.fr writes:
[...]
| La norme est assez clair que l'accès à un objet volatile doit avoir
| lieu
| avant le point de séquencement suivant.
et elle est aussi assez claire sur le fait que l'objet peut être
modifié de manière inconnue du compilateur ou tout ce que tu veux. Un
load ou store supplémentaire -- à l'insu de son plein gré -- devient
alors tout à fait valide, de même qu'un load ou ou store en
moins. Bref.
| En ce qui concerne la synchronisation, je crois que c'est assez clair
| aussi que le comportement particulier des objets volatile ne concerne
| que les objets volatile, c-à-d que le compilateur est libre à
| déplacer
| les autres accès comme il veut, dans la mésure que ça ne change pas
| ce
| qu'on écrit à un volatile ou qu'on écrit vers une sortie (FILE* ou
| streambuf).
Et pourtant, ce n'est pas ce qu'elle dit -- et de fait l'écriture dans
un objet volatile peut changer complètement le reste du fonctionnement
du programme, y compris les valeurs des objets non volatiles.
La restriction que "volatile" n'affecte que les objets volatiles est
un changement fondamental, qui n'est pas du tout dans la spécification
actuelle. Il y a de l'abus dans ton « c'est assez clair ».
| La norme est assez clair que l'accès à un objet volatile doit avoir | lieu | avant le point de séquencement suivant.
et elle est aussi assez claire sur le fait que l'objet peut être modifié de manière inconnue du compilateur ou tout ce que tu veux. Un load ou store supplémentaire -- à l'insu de son plein gré -- devient alors tout à fait valide, de même qu'un load ou ou store en moins. Bref.
| En ce qui concerne la synchronisation, je crois que c'est assez clair | aussi que le comportement particulier des objets volatile ne concerne | que les objets volatile, c-à-d que le compilateur est libre à | déplacer | les autres accès comme il veut, dans la mésure que ça ne change pas | ce | qu'on écrit à un volatile ou qu'on écrit vers une sortie (FILE* ou | streambuf).
Et pourtant, ce n'est pas ce qu'elle dit -- et de fait l'écriture dans un objet volatile peut changer complètement le reste du fonctionnement du programme, y compris les valeurs des objets non volatiles.
La restriction que "volatile" n'affecte que les objets volatiles est un changement fondamental, qui n'est pas du tout dans la spécification actuelle. Il y a de l'abus dans ton « c'est assez clair ».
-- Gaby
Gabriel Dos Reis
Jean-Marc Bourguet writes:
[...]
| > La norme est assez clair que l'accès à un objet volatile doit avoir | > lieu avant le point de séquencement suivant. | | Oui, mais il y a la regle du as-if. Les compilateurs deplacent tout | le temps des choses au-dela des points de sequencement avec cette | regle vu la formulation ("agressive optimisation involving the | [volatile] object") je ne crois pas que ce soit interdit. Le | deplacement ne concerne pas l'objet volatile.
Tout à fait. Mais également, c'est aussi du n'importe quoi parce que volatile peut avoir un effet inconnu du compilateur -- par exemple, le programme ne fonctionne plus comme il devrait.
[...]
| > Avec les threads Posix. Probablement avec les threads Windows aussi. | > Mais on peut bien imaginer des modèles de thread où son utilisation | > aurait un sens. | | J'ai l'impression que plus le temps passe, moins on a de garantie et | je ne vois pas de renversement de tendance.
Comme dirait Dennis Ritchie, l'une des principales vertus de « volatile », c'est qu'on peut l'oublier.
C'était probablement une bonne idée abstraite au départ, mais son accouchement est un non-sens qu'il vaut probablement mieux laisser mourir sa mort pas du tout prématurée. Pas d'acharnement thérapeutique.
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| > La norme est assez clair que l'accès à un objet volatile doit avoir
| > lieu avant le point de séquencement suivant.
|
| Oui, mais il y a la regle du as-if. Les compilateurs deplacent tout
| le temps des choses au-dela des points de sequencement avec cette
| regle vu la formulation ("agressive optimisation involving the
| [volatile] object") je ne crois pas que ce soit interdit. Le
| deplacement ne concerne pas l'objet volatile.
Tout à fait. Mais également, c'est aussi du n'importe quoi parce que
volatile peut avoir un effet inconnu du compilateur -- par exemple, le
programme ne fonctionne plus comme il devrait.
[...]
| > Avec les threads Posix. Probablement avec les threads Windows aussi.
| > Mais on peut bien imaginer des modèles de thread où son utilisation
| > aurait un sens.
|
| J'ai l'impression que plus le temps passe, moins on a de garantie et
| je ne vois pas de renversement de tendance.
Comme dirait Dennis Ritchie, l'une des principales vertus de
« volatile », c'est qu'on peut l'oublier.
C'était probablement une bonne idée abstraite au départ, mais son
accouchement est un non-sens qu'il vaut probablement mieux laisser
mourir sa mort pas du tout prématurée. Pas d'acharnement
thérapeutique.
| > La norme est assez clair que l'accès à un objet volatile doit avoir | > lieu avant le point de séquencement suivant. | | Oui, mais il y a la regle du as-if. Les compilateurs deplacent tout | le temps des choses au-dela des points de sequencement avec cette | regle vu la formulation ("agressive optimisation involving the | [volatile] object") je ne crois pas que ce soit interdit. Le | deplacement ne concerne pas l'objet volatile.
Tout à fait. Mais également, c'est aussi du n'importe quoi parce que volatile peut avoir un effet inconnu du compilateur -- par exemple, le programme ne fonctionne plus comme il devrait.
[...]
| > Avec les threads Posix. Probablement avec les threads Windows aussi. | > Mais on peut bien imaginer des modèles de thread où son utilisation | > aurait un sens. | | J'ai l'impression que plus le temps passe, moins on a de garantie et | je ne vois pas de renversement de tendance.
Comme dirait Dennis Ritchie, l'une des principales vertus de « volatile », c'est qu'on peut l'oublier.
C'était probablement une bonne idée abstraite au départ, mais son accouchement est un non-sens qu'il vaut probablement mieux laisser mourir sa mort pas du tout prématurée. Pas d'acharnement thérapeutique.
-- Gaby
Gabriel Dos Reis
writes:
[...]
| Mais c'est effectivement important à noter qu'au contraire de mutable, | il fait bien partie du système de types.
Ah, « mutable » ne fait plus partie du système de type. Depuis quand ?
-- Gaby
kanze@gabi-soft.fr writes:
[...]
| Mais c'est effectivement important à noter qu'au contraire de mutable,
| il fait bien partie du système de types.
Ah, « mutable » ne fait plus partie du système de type. Depuis quand ?
On Wed, 22 Dec 2004 23:24:28 +0100, "PRORIOL Fabien" :
init() et lire() ne modifie en rien la structure de donné
Je ne suis pas d'accord. Deux appels consécutifs à lire() ne donnent pas le même résultat, donc lire() modifie bel et bien l'état de l'objet.
-- ;-)
drkm
"Alain Naigeon" writes:
"drkm" a écrit dans le message news:
7.1.5.1/8 :
[Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation.
Évidemment, ça aide pas.
Je prends en route, donc, si ce texte laisse de côté une question précise que vous auriez évoquée, je me retire sur la pointe des pieds. Ceci dit, veux-tu dire que le texte ci-dessus n'est pas clair ? Je le trouve limpide, pour ma part.
Limpide ? En quelque sorte, oui. Il est clair en ce qu'il définit une nébuleuse inutilisable en pratique. « undetectable by an implementation », c'est clair, oui.
--drkm
"Alain Naigeon" <anaigeon@free.fr> writes:
"drkm" <usenet.fclcxx@fgeorges.org> a écrit dans le message news:
wk8y7pvkh7.fsf@fgeorges.org...
7.1.5.1/8 :
[Note: volatile is a hint to the implementation to avoid
aggressive optimization involving the object because the value of
the object might be changed by means undetectable by an
implementation.
Évidemment, ça aide pas.
Je prends en route, donc, si ce texte laisse de côté une question
précise que vous auriez évoquée, je me retire sur la pointe des
pieds.
Ceci dit, veux-tu dire que le texte ci-dessus n'est pas clair ? Je le
trouve limpide, pour ma part.
Limpide ? En quelque sorte, oui. Il est clair en ce qu'il définit
une nébuleuse inutilisable en pratique. « undetectable by an
implementation », c'est clair, oui.
[Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation.
Évidemment, ça aide pas.
Je prends en route, donc, si ce texte laisse de côté une question précise que vous auriez évoquée, je me retire sur la pointe des pieds. Ceci dit, veux-tu dire que le texte ci-dessus n'est pas clair ? Je le trouve limpide, pour ma part.
Limpide ? En quelque sorte, oui. Il est clair en ce qu'il définit une nébuleuse inutilisable en pratique. « undetectable by an implementation », c'est clair, oui.
--drkm
drkm
Jean-Marc Bourguet writes:
A ma connaissance, le seul effet definit par le langage qu'a volatile est celui de rendre valide certaines lectures apres un longjmp (et encore, j'ai pas les normes sous la main et je me demande maintenant si celle du C++ n'enleve pas une partie de ce que dit celle du C)
La suite de 7.1.5.1/8 :
In general, the semantics of volatile are intended to be the same in C++ as they are in C.]
À noter le « in general ». Bien que, si l'intention est de reprendre la sémantique du C, je ne vois pas trop l'intérêt du « in general ».
--drkm
Jean-Marc Bourguet <jm@bourguet.org> writes:
A ma connaissance, le seul effet definit par le langage qu'a volatile
est celui de rendre valide certaines lectures apres un longjmp (et
encore, j'ai pas les normes sous la main et je me demande maintenant
si celle du C++ n'enleve pas une partie de ce que dit celle du C)
La suite de 7.1.5.1/8 :
In general, the semantics of volatile are intended to be the same
in C++ as they are in C.]
À noter le « in general ». Bien que, si l'intention est de
reprendre la sémantique du C, je ne vois pas trop l'intérêt du « in
general ».
A ma connaissance, le seul effet definit par le langage qu'a volatile est celui de rendre valide certaines lectures apres un longjmp (et encore, j'ai pas les normes sous la main et je me demande maintenant si celle du C++ n'enleve pas une partie de ce que dit celle du C)
La suite de 7.1.5.1/8 :
In general, the semantics of volatile are intended to be the same in C++ as they are in C.]
À noter le « in general ». Bien que, si l'intention est de reprendre la sémantique du C, je ne vois pas trop l'intérêt du « in general ».
--drkm
drkm
writes:
Mais ce qui constitue un accès dans cette contexte est défini par l'implémentation.
Même pas, « because the value of the object might be changed by means undetectable by an implementation ».
--drkm
kanze@gabi-soft.fr writes:
Mais ce qui constitue un accès dans cette contexte est
défini par l'implémentation.
Même pas, « because the value of the object might be changed by
means undetectable by an implementation ».
Mais ce qui constitue un accès dans cette contexte est défini par l'implémentation.
Même pas, « because the value of the object might be changed by means undetectable by an implementation ».
--drkm
Gabriel Dos Reis
drkm writes:
| Jean-Marc Bourguet writes: | | > A ma connaissance, le seul effet definit par le langage qu'a volatile | > est celui de rendre valide certaines lectures apres un longjmp (et | > encore, j'ai pas les normes sous la main et je me demande maintenant | > si celle du C++ n'enleve pas une partie de ce que dit celle du C) | | La suite de 7.1.5.1/8 : | | In general, the semantics of volatile are intended to be the same | in C++ as they are in C.] | | À noter le « in general ». Bien que, si l'intention est de | reprendre la sémantique du C, je ne vois pas trop l'intérêt du « in | general ».
Ça veut dire quoi en C, une fonction virtuelle avec « volatile » comme cv-qualifier ?
Remarque aussi que c'est une « note », donc non-normative.
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Jean-Marc Bourguet <jm@bourguet.org> writes:
|
| > A ma connaissance, le seul effet definit par le langage qu'a volatile
| > est celui de rendre valide certaines lectures apres un longjmp (et
| > encore, j'ai pas les normes sous la main et je me demande maintenant
| > si celle du C++ n'enleve pas une partie de ce que dit celle du C)
|
| La suite de 7.1.5.1/8 :
|
| In general, the semantics of volatile are intended to be the same
| in C++ as they are in C.]
|
| À noter le « in general ». Bien que, si l'intention est de
| reprendre la sémantique du C, je ne vois pas trop l'intérêt du « in
| general ».
Ça veut dire quoi en C, une fonction virtuelle avec « volatile » comme
cv-qualifier ?
Remarque aussi que c'est une « note », donc non-normative.
| Jean-Marc Bourguet writes: | | > A ma connaissance, le seul effet definit par le langage qu'a volatile | > est celui de rendre valide certaines lectures apres un longjmp (et | > encore, j'ai pas les normes sous la main et je me demande maintenant | > si celle du C++ n'enleve pas une partie de ce que dit celle du C) | | La suite de 7.1.5.1/8 : | | In general, the semantics of volatile are intended to be the same | in C++ as they are in C.] | | À noter le « in general ». Bien que, si l'intention est de | reprendre la sémantique du C, je ne vois pas trop l'intérêt du « in | general ».
Ça veut dire quoi en C, une fonction virtuelle avec « volatile » comme cv-qualifier ?
Remarque aussi que c'est une « note », donc non-normative.
-- Gaby
Gabriel Dos Reis
drkm writes:
| "Alain Naigeon" writes: | | > "drkm" a écrit dans le message news: | > | | >> 7.1.5.1/8 : | | >> [Note: volatile is a hint to the implementation to avoid | >> aggressive optimization involving the object because the value of | >> the object might be changed by means undetectable by an | >> implementation. | | >> Évidemment, ça aide pas. | | > Je prends en route, donc, si ce texte laisse de côté une question | > précise que vous auriez évoquée, je me retire sur la pointe des | > pieds. | > Ceci dit, veux-tu dire que le texte ci-dessus n'est pas clair ? Je le | > trouve limpide, pour ma part. | | Limpide ? En quelque sorte, oui. Il est clair en ce qu'il définit | une nébuleuse inutilisable en pratique. « undetectable by an | implementation », c'est clair, oui.
Bref, le compilo peut toujours pondre du code buggué, ce sera la faute de « means undetectable by an implementation. » Hello Alpha du Centaure, vous me recevez ? Arrêtez de faire planter mon programme.
Comment dit-on euthanasie en standardese ?
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| "Alain Naigeon" <anaigeon@free.fr> writes:
|
| > "drkm" <usenet.fclcxx@fgeorges.org> a écrit dans le message news:
| > wk8y7pvkh7.fsf@fgeorges.org...
|
| >> 7.1.5.1/8 :
|
| >> [Note: volatile is a hint to the implementation to avoid
| >> aggressive optimization involving the object because the value of
| >> the object might be changed by means undetectable by an
| >> implementation.
|
| >> Évidemment, ça aide pas.
|
| > Je prends en route, donc, si ce texte laisse de côté une question
| > précise que vous auriez évoquée, je me retire sur la pointe des
| > pieds.
| > Ceci dit, veux-tu dire que le texte ci-dessus n'est pas clair ? Je le
| > trouve limpide, pour ma part.
|
| Limpide ? En quelque sorte, oui. Il est clair en ce qu'il définit
| une nébuleuse inutilisable en pratique. « undetectable by an
| implementation », c'est clair, oui.
Bref, le compilo peut toujours pondre du code buggué, ce sera la faute
de « means undetectable by an implementation. » Hello Alpha du
Centaure, vous me recevez ? Arrêtez de faire planter mon programme.
| "Alain Naigeon" writes: | | > "drkm" a écrit dans le message news: | > | | >> 7.1.5.1/8 : | | >> [Note: volatile is a hint to the implementation to avoid | >> aggressive optimization involving the object because the value of | >> the object might be changed by means undetectable by an | >> implementation. | | >> Évidemment, ça aide pas. | | > Je prends en route, donc, si ce texte laisse de côté une question | > précise que vous auriez évoquée, je me retire sur la pointe des | > pieds. | > Ceci dit, veux-tu dire que le texte ci-dessus n'est pas clair ? Je le | > trouve limpide, pour ma part. | | Limpide ? En quelque sorte, oui. Il est clair en ce qu'il définit | une nébuleuse inutilisable en pratique. « undetectable by an | implementation », c'est clair, oui.
Bref, le compilo peut toujours pondre du code buggué, ce sera la faute de « means undetectable by an implementation. » Hello Alpha du Centaure, vous me recevez ? Arrêtez de faire planter mon programme.
