Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ signification de mutable et volatile

signification de mutable et volatile

83 réponses
Avatar
Stephane Wirtel
Bonjour à tous,

Lisant parfois du code avec ces mots réservés, je me demande maintenant
quelles sont les fonctionnalités de ces deux mots.

Une petite explication ou une doc m'expliquant clairement le but de ces
deux mots réservés.

Merci,

Stéphane.
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
3 4 5 6 7
Avatar
drkm
"Alain Naigeon" writes:

la promesse
donnée par le mot "volatile"


Mais quelle est-elle ?

--drkm

Avatar
kanze
drkm wrote:
writes:

drkm wrote:

Mais ce qui constitue un accès dans cette
contexte est défini par l'implémentation.




Ce à quoi j'ai répondu :

Même pas, « because the value of the object might be
changed by means undetectable by an implementation ».



Quelque chose qui échappe à une implémentation n'est pas
défini par elle. Si ?


Mais quel rapport. Tous les « accès » ne proviennent pas de
l'implémentation, et surtout, on considère ici la
possibilité que la valeur peut changer sans un accès.


Mais comment une implémentation peut-elle « définir » ce
qu'est un accès lorsque tout peut arriver par ailleurs ?


Quel rapport ? Les accès, c'est l'implémentation qui les font et
les définit. La particularité, c'est que 1) la valeur de l'objet
peut changer sans accès de l'implémentation, et 2) ces accès
font partie du comportement visible.

--
James Kanze GABI Software http://www.gabi-soft.fr
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






Avatar
kanze
drkm wrote:
writes:

drkm wrote:

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 ».


Ça, c'est un autre aspect. Ici, il n'est question que des
« accès » par l'implémentation.


Est-il possible pour l'implémentation de « définir » les
accès à des « choses » sur lesquelles elle ne peut avoir
aucune garantie ?


Je ne comprends pas le sens de la question. Un accès par le code
généré par l'implémentation est un comportement visible, au sens
de la norme. L'implémentation définit ce qu'il entend par
« accès » dans ce cas-là. Elle peut bien garantir ce qu'elle
fait, non.

À titre d'exemple, g++ ou Sun CC sur Sparc semblent définir un
accès comme la simple exécution d'une instruction de lecture ou
d'écriture. D'une côté, c'est une définition sans la moindre
utilité, mais de l'autre, avant l'apparition des systèmes
multi-CPU au moins (et même après, mais là on pourrait en
discuter), c'est suffisant dans un programme utilisateur (qui ne
tourne pas comme root, et qui n'a pas accès direct au hardware)
-- dans un tel programme, à peu près tout ce qu'on peut faire
avec volatile, c'est s'en servir comme décrit dans la norme pour
les longjmp/setjmp ou avec sig_atomic_t.

Sur un processeur embarqué, avec un noyau temps-réel, et où les
adresses d'un processus correspondent réelement aux adresses
hardware sur le bus mémoire ou le bus IO, je m'attendrais à ce
qu'une inplémentation définisse bien qu'un accès est quelque
chose qui se propage jusqu'au bus. C-à-d que si j'écris :

unsigned int volatile* realTimeClock
= reinterpret_cast< unsigned int* >( 0x1234 ) ;

unsigned int now ;

now = *realTimeClose ;

Qu'il y ait bien une lecture réele sur le bus externe chaque
fois que la dernière instruction est exécutée.

--
James Kanze GABI Software http://www.gabi-soft.fr
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




Avatar
drkm
"Alain Naigeon" writes:

"drkm" a écrit dans le message news:


"Alain Naigeon" writes:

la promesse
donnée par le mot "volatile"


Mais quelle est-elle ?


T'as oublié de lire avant de tronquer une citation


Non.

(pratique peu recommandée, soit dit en passant)


En effet.

Donc la promesse en question serait selon toi : « générer quelque
chose d'assez proche de ce que j'ai écrit pour qu'en aucune
circonstance le résultat ne soit différent d'une traduction totalement
fidèle ». D'où tires-tu cela ?

--drkm



Avatar
drkm
writes:

drkm wrote:

writes:

drkm wrote:

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 ».


Ça, c'est un autre aspect. Ici, il n'est question que des
« accès » par l'implémentation.


Est-il possible pour l'implémentation de « définir » les
accès à des « choses » sur lesquelles elle ne peut avoir
aucune garantie ?


Je ne comprends pas le sens de la question. Un accès par le code
généré par l'implémentation est un comportement visible, au sens
de la norme. L'implémentation définit ce qu'il entend par
« accès » dans ce cas-là. Elle peut bien garantir ce qu'elle
fait, non.


1.9/5 :

A conforming implementation executing a well-formed program shall
produce the same observable behavior as one of the possible
execution sequences of the corresponding instance of the abstract
machine with the same program and the same input.

1.9/6 :

The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O
functions.

Elle peut « définir » ce qu'elle a décidé de faire lors d'un accès à
une donnée volatile, mais pas l'état observable de la machine
abstraite. Quel est l'intérêt d'une telle « définition » ?

--drkm





Avatar
drkm
writes:

drkm wrote:

writes:

drkm wrote:

Mais ce qui constitue un accès dans cette
contexte est défini par l'implémentation.




Ce à quoi j'ai répondu :

Même pas, « because the value of the object might be
changed by means undetectable by an implementation ».



Quelque chose qui échappe à une implémentation n'est pas
défini par elle. Si ?


Mais quel rapport. Tous les « accès » ne proviennent pas de
l'implémentation, et surtout, on considère ici la
possibilité que la valeur peut changer sans un accès.


Mais comment une implémentation peut-elle « définir » ce
qu'est un accès lorsque tout peut arriver par ailleurs ?


Quel rapport ? Les accès, c'est l'implémentation qui les font et
les définit. La particularité, c'est que 1) la valeur de l'objet
peut changer sans accès de l'implémentation, et 2) ces accès
font partie du comportement visible.


Je ne te comprends pas. Parles-tu de l'état observable de la
machine abstraite, ou de ce que l'implémentation clame entreprendre
lorsqu'elle réalise un accès à une donnée volatile ? Si tu parles de
l'état observable, l'implémentation ne peut pas définir un accès.

--drkm







Avatar
drkm
"Alain Naigeon" writes:

C'est le sens (figuré ) du mot volatile, aussi bien an Français qu'en
Anglais :-)


Est-ce suffisant pour parler de « promesse », dans le contexte de
C++ ?

--drkm

Avatar
kanze
drkm wrote:
writes:

drkm wrote:

writes:

drkm wrote:

Mais ce qui constitue un accès dans
cette contexte est défini par l'implémentation.




Ce à quoi j'ai répondu :

Même pas, « because the value of the object might
be changed by means undetectable by an
implementation ».



Quelque chose qui échappe à une implémentation n'est
pas défini par elle. Si ?


Mais quel rapport. Tous les « accès » ne proviennent pas
de l'implémentation, et surtout, on considère ici la
possibilité que la valeur peut changer sans un accès.


Mais comment une implémentation peut-elle « définir » ce
qu'est un accès lorsque tout peut arriver par ailleurs ?


Quel rapport ? Les accès, c'est l'implémentation qui les
font et les définit. La particularité, c'est que 1) la
valeur de l'objet peut changer sans accès de
l'implémentation, et 2) ces accès font partie du
comportement visible.


Je ne te comprends pas. Parles-tu de l'état observable de
la machine abstraite, ou de ce que l'implémentation clame
entreprendre lorsqu'elle réalise un accès à une donnée
volatile ? Si tu parles de l'état observable,
l'implémentation ne peut pas définir un accès.


Je n'ai pas parlé de l'état observable, mais du « comportement
observable » ; le « observable behavior » du §1.9 dans la
norme. Ce qui intéresse l'implémentation, en ce qui concerne des
accès volatile, ce n'est pas un état, mais ce qu'a fait
l'implémentatiom. Un des caractèristiques d'un volatile,
précisement, c'est que l'implémentation est sensée ne pas
pouvoir en deduire l'état à partir des son comportement. Donc,
elle ne peut pas effectuer des optimisations qui se base sur
l'état deduit.

(Dans le suivant, je me base sur la norme C, qui est beaucoup
plus claire que la norme C++. Mais l'intention de la norme C++
est clairement que « the semantics of volatiole are intended to
be the same in C++ as they are in C. »)

Considérons un cas simple, l'expression *p désignant un unsigned
char :
*p = 0x82 ;
printf( "%02xn", *p ) ;

Sans volatile, le compilateur peut facilement déduire l'état de
*p dans la deuxième expression, et convertir l'expression en :
printf( "%02xn", 0x82 ) ;
En plus, s'il peut démontrer qu'on n'accède pas à l'objet
désigné par *p ailleurs, il pourait supprimé l'écriture ; étant
donné que si la deuxième expression modifier l'état de *p, on
aurait un comportement indéfini, il peut facilement déplacer
l'écriture après la deuxième expression s'il l'a transformé
comme ci-dessus.

Si le type de *p est « unsigned int volatile », en révanche,
rien de ça ne vaut. Premièrement, le compiateur ne peut rien
déduire sur l'état de *p dans la deuxième expression, parce que
« an object that has volatile-qualified type may be modified in
ways unknown to the implementation » (§6.7.3/6). En plus, le
compilateur est obligé à effectuer les accès définis par la
machine abstraite -- c-à-d l'écriture dans la première
expression, et la lecture dans la deuxième. Et c'est ici (et ici
seulement) qu'on laisse la liberté à l'implémentation -- c'est à
l'implémentation de définir ce qu'il entend par « accès » (en
fait, accès en lecture et accès en écriture). Mais note bien que
la norme dit clairement qu'il ne s'agit pas des « valeurs » qui
ne changent pas : « At sequence points, volatile objects are
stable in the sense that previous accesses are complete and
subsequent accesses have not yet occurred ». L'utilisation du
mot « stable » dans cette contexte n'est pas à mon avis
particulièrement heureuse, mais la texte qui suit clarifie bien
qu'on s'intéresse aux actions de lire et d'écrire
(« accesses »), et non de l'état même de l'objet. Dans la
première expression, donc, le compilateur est obligé à réelement
écrire *p (pour sa propre définition d'écrire). La deuxième
expression est un peu plus compliquée : il est obligé de
réelement lire la valeur *p (pour sa propre définition de lire),
et qu'à la fin du programme, la valeur de ce qu'il a lu,
converti en texte, apparaît dans le fichier de sortie standard.

--
James Kanze GABI Software http://www.gabi-soft.fr
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








Avatar
kanze
drkm wrote:
writes:

drkm wrote:

writes:

drkm wrote:

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 ».


Ça, c'est un autre aspect. Ici, il n'est question que des
« accès » par l'implémentation.


Est-il possible pour l'implémentation de « définir » les
accès à des « choses » sur lesquelles elle ne peut avoir
aucune garantie ?


Je ne comprends pas le sens de la question. Un accès par le
code généré par l'implémentation est un comportement
visible, au sens de la norme. L'implémentation définit ce
qu'il entend par « accès » dans ce cas-là. Elle peut bien
garantir ce qu'elle fait, non.


1.9/5 :

A conforming implementation executing a well-formed
program shall produce the same observable behavior as one
of the possible execution sequences of the corresponding
instance of the abstract machine with the same program and
the same input.

1.9/6 :

The observable behavior of the abstract machine is its
sequence of reads and writes to volatile data and calls to
library I/O functions.

Elle peut « définir » ce qu'elle a décidé de faire lors d'un
accès à une donnée volatile, mais pas l'état observable de la
machine abstraite. Quel est l'intérêt d'une telle
« définition » ?


Ça dépend de la définition:-). C'est une question de la qualité
de l'implémentation d'en donner une définition utile. Dans le
cas, au moins, où l'utilisation des volatiles (autre que
sig_atomic_t) a un sens -- ni Sun CC ni g++ sur Sparc/Solaris ne
lui donne une définition utile, mais dans la pratique, sauf si
on écrit du code pour le noyau, et à part sig_atomic_t, il n'y a
aucun intérêt à utiliser volatile. Quelque soit la définition
qu'ils lui donnent. Mais le C et le C++ ne sont pas conçu pour
servir uniquement dans les applications sur des systèmes
généralistes avec un OS élaboré qui empèche de toute façon des
accès de bas niveau. Je me suis déjà servi du C sur des systèmes
où j'accédais directement à la porte série, par exemple -- quand
tu initialises un Intel 8251, par exemple, il faut commencer par
écrire trois fois un 0x00 dans la porte de commande, et là, je
peux t'assurer, volatile est bien utile.

--
James Kanze GABI Software http://www.gabi-soft.fr
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






Avatar
drkm
writes:

Je n'ai pas parlé de l'état observable, mais du « comportement
observable »


Ok, je comprends maintenant. Merci.

--drkm

3 4 5 6 7