strange grammar about volatile and operator overload

[George2]

Hello everyone,
The following code,

operator const Outer::Inner * volatile & ();
 

1.

I think it means an operator &, which returns const Inner* type and
takes no arguments, right?

2.

Adding volatile to return value means?

(I previously only used volatile to qualify variable)
thanks in advance,
George

[Hans Mull]

George2 schrieb:

Hello everyone,
The following code,

operator const Outer::Inner * volatile & ();
 

1.

I think it means an operator &, which returns const Inner* type and
takes no arguments, right?

2.

Adding volatile to return value means?

(I previously only used volatile to qualify variable)
thanks in advance,
George

volaitle disables optimization

Kind regards

[Jack Klein]

On Tue, 29 Jan 2008 14:13:07 +0100, Hans Mull
<de*******@googlemail.comwrote in comp.lang.c++:

George2 schrieb:

Hello everyone,
The following code,

 operator const Outer::Inner * volatile & ();
 

1.

I think it means an operator &, which returns const Inner* type and
takes no arguments, right?

2.

Adding volatile to return value means?

(I previously only used volatile to qualify variable)
thanks in advance,
George

volaitle disables optimization

What a silly, incomplete, and absolutely wrong statement!

Consider this code:

extern volatile unsigned int vui; // defined and initialized elsewhere

unsigned int silly_func()
{
return vui * 2;
}

Are you really claiming that the compiler is forbidden from making the
strength reduction optimization of replacing the multiply with a left
shift by 1?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Gerhard Fiedler]

On 2008-01-30 08:50:26, James Kanze wrote:

what's important here isn't the semantics of volatile, but the fact that
T* volatile isn't the same type as T* volatile.)

Is this a typo? If not, could you please explain?

In sum, the implementation defined semantics of volatile are, in most
cases, totally useless for anything.

Does this mean that it is not necessary to declare variables that are
accessed (read and write) by different threads as volatile? (In addition to
the necessary locking, of course.)

Gerhard

[Diego Martins]

On Jan 30, 10:00 am, Gerhard Fiedler <[e-mail]:

On 2008-01-30 08:50:26, James Kanze wrote:

what's important here isn't the semantics of volatile, but the fact that
T* volatile isn't the same type as T* volatile.)

Is this a typo? If not, could you please explain?

In sum, the implementation defined semantics of volatile are, in most
cases, totally useless for anything.

Does this mean that it is not necessary to declare variables that are
accessed (read and write) by different threads as volatile? (In addition to
the necessary locking, of course.)

Gerhard

I will extend the Gerhard's question to: "and what about pointer to
memory mapped addresses?"

Diego

[James Kanze]

On Jan 30, 1:00 pm, Gerhard Fiedler <[e-mail]:

On 2008-01-30 08:50:26, James Kanze wrote:

what's important here isn't the semantics of volatile, but the fact that
T* volatile isn't the same type as T* volatile.)

Is this a typo?

I think so:-). What I probably meant to say was that T*& isn't
the same as T* volatile&. (Note that T* volatile and T* are the
same types, at least when they're return values.)

[...]

In sum, the implementation defined semantics of volatile
are, in most cases, totally useless for anything.

Does this mean that it is not necessary to declare variables
that are accessed (read and write) by different threads as
volatile? (In addition to the necessary locking, of course.)

It depends on what the threading specifications (and the
compiler definition of volatile) say. Under Posix, if you
haven't locked, volatile isn't sufficient, and if you have, it
isn't necessary. Current Windows works about the same, I think,
although I find it very hard to find any real published
specifications.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]