[cpp-threads] static locals

[Boehm, Hans]

I understand.

But so far, having the compiler perform an initialization statically,
when it is not required to, should be transparent to all reasonable
code.  It is detectable, but it isn't very natural to write code
that depends on the initialization happening dynamically.

In the multithreaded case, I think it will not be that unusual that
static initialization would break the code, since the necessary
memory ordering would no longer be enforced.  If we allow static
initialization only for constant expressions, then we might start
to see bogus casts or other mechanisms solely to force something
not to be a constant expression.  This bothers me.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Peter Dimov
> Sent: Tuesday, May 31, 2005 11:57 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] static locals
> 
> 
> Boehm, Hans wrote:
> 
> > 2) (More important to me personally.)  Distinguishing the 
> static and 
> > dynamic case here seems very ugly to me.
> 
> The standard already distinguishes between static and dynamic 
> initialization. See 6.7/4 and 3.6.2. We aren't inventing 
> anything new, we 
> are just clarifying the semantics of "the first time control 
> passes through 
> its declaration" by saying what happens in the presence of 
> control races, 
> and specifying the visibility semantics of "is considered 
> initialized" 
> (citations are from 6.7/4). 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk