In article <1993May14.062518.21832@ucc.su.OZ.AU>
maxtal@physics.su.OZ.AU (John Max Skaller) writes:

|> In article <KANZE.93May4122707@slsvdnt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|> >In article <1993May1.163358.28019@ucc.su.OZ.AU>
|> >maxtal@physics.su.OZ.AU (John Max Skaller) writes:

|> >|> >Okay, here's a simple one....what is a volatile member function?

|> >|>  class X {
|> >|>   int i;
|> >|>  public:
|> >|>   int get()volatile { return i+i+i+i; }
|> >|>  };

|> >|>  volatile X x;
|> >|>  x.get(); // OK

|> >|> What does this mean? Not sure :-(

|> >To start with, declaring the function volatile means that you can call
|> >it on a volatile object:-).

|>  Yes, thats right.

|> >|> Maybe its a routine that doesnt optimise away references to 'i'
|> >|> (and write i<<2 on the last line)?

|> >It means that the compiler is obiged to read x.i four times in X::get,
|> >instead of just once.

|> >Basically, declaring x volatile makes a statement to the compiler
|> >concerning the *data* members of x, mainly that they may change value
|> >in ways unknowable to the compiler (modified in interupts, memory
|> >mapped IO, etc.).

|>  I agree with this idea, but I am uncertain what the Standard
|> actually says about the semantics of volatile.

To quote the current draft (unchanged, I think, from the ARM):

 There are no implementation-independent semantics for volatile
 objects; volatile is a hint to the compiler to avoid
 aggressive optimization involving the object because the value
 of the object may be changed by means undetectable by a
 compiler.

Which doesn't guarentee very much.

The C standard is somewhat more explicit:

 An object that has volatile-qualified type may be modified in
 ways unknown to the implementation or have other unknown side
 effects.  Therefore any expression referring to such an object
 shall be evaluated stricly according to the rules of the
 abstract machine, as described in 2.1.2.3.  Furthermore, at
 every sequence point the value last stored in the object shall
 agree with that prescribed by the abstract machine, except as
 modified by the unknown factors mentioned above.  What
 constitutes an access to an object that has volatile-qualified
 type is implementation-defined.

The C++ standard seems only to have retained the last sentence:-(.

The C standard also makes further mention of volatile semantics with
regards to 'longjmp' and 'signal'.  These qualifications have been
incorporated in the current draft of the C++ standard, since the C
library was taken over almost as is.

In practice, I don't think that there will be a real issue.  Most
programmers will never need nor want volatile; those that do will be
capable enough to ask the correct questions of their vendors (and
insist on the correct answers).  As a quality of implementation issue;
any C++ implementation not maintaining at least as much as the C
standard implies would probably be considered fatally flawed by anyone
needing volatile.  I personally would also expect that the guarentees
concerning 'longjmp' also be extended to exceptions in any compiler
supporting exceptions.  (On the other hand, I would prefer that the
standards define the state of all local variables after an exception
is caught, and not just those qualified as volatile.)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <KANZE.93May4122707@slsvdnt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <1993May1.163358.28019@ucc.su.OZ.AU>
>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>|> >Okay, here's a simple one....what is a volatile member function?
>
>|>  class X {
>|>   int i;
>|>  public:
>|>   int get()volatile { return i+i+i+i; }
>|>  };
>
>|>  volatile X x;
>|>  x.get(); // OK
>
>|> What does this mean? Not sure :-(
>
>To start with, declaring the function volatile means that you can call
>it on a volatile object:-).

 Yes, thats right.
>
>|> Maybe its a routine that doesnt optimise away references to 'i'
>|> (and write i<<2 on the last line)?
>
>It means that the compiler is obiged to read x.i four times in X::get,
>instead of just once.
>
>Basically, declaring x volatile makes a statement to the compiler
>concerning the *data* members of x, mainly that they may change value
>in ways unknowable to the compiler (modified in interupts, memory
>mapped IO, etc.).

 I agree with this idea, but I am uncertain what the Standard
actually says about the semantics of volatile.

 Until recently, maybe it didnt matter. However, based on
the 'common' interpretation of volatile given above, the idea
that was also commonly held that volatile pointer conversions
mirrored const pointer conversions in their 'const correct'
attributes was shown by Pat Smith to be false.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA