Re: volatile [was: GCC warnings for unused global variables]

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 06-May-2003, Alexandre Oliva <aoliva@redhat.com> wrote:
> On May  4, 2003, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> 
> >> They can be
> >> created with the initialized value, if that can be calculated at
> >> compile time (e.g., if there is no constructor).
> 
> > That is true for non-volatile variables, but only because the compiler
> > can apply the as-if rule.  As discussed earlier in this thread, the
> > as-if rule does not apply to volatile variables -- the standard prohibits
> > implementations from optimizing away accesses to volatile variables.
> 
> Except that the object only becomes volatile after it is initialized.
> Otherwise, there'd be no constructor to initialize it, since
> cv-qualifiers don't make it to the type of `this' in cdtors.

Hmm, good point.  But the C++ standard doesn't say much about the behaviour
of volatile during construction/deconstruction (or if it does, I missed
it). 

The standard doesn't say an object only becomes volatile after it is
initialized.  The standard just says (7.1.5.1/7):

 | 	If an attempt is made to refer to an object defined with a
 | 	volatile-qualified type through the use of an lvalue with a
 | 	non-volatile-qualified type, the program behaviour is undefined.

Note that unlike the analagous wording for "const" (7.1.5.1/4),
this is *not* restricted to "during its lifetime".

Of course, the standard does contain the general clause
"The properties ascribed to objects throughout this International
Standard apply for a given object only during its lifetime." (3.8/3).
So you could argue that 7.1.5.1/7 doesn't apply before the constructor
is complete.  However, in the lack of any explicit definition of what
it means to refer to a volatile-qualified object through a non-volatile
qualified type would tend to suggest that the behaviour was implicitly
undefined anyway, even if not explicitly undefined.

But more to the point, volatile is generally used with PODs/aggregates,
in which case there is no constructor to worry about, just an initializer.
The C++ committee was not too worried about nailing down the semantics
of volatile for class objects, since they did not expect it to be used
(or useful) for class objects.

In the case of aggregates, there is no constructor, and the lifetime
begins as soon as the storage is allocated (i.e. before it even gets
zero-initialized).  So the properties of "volatile" should hold from
then on.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.