This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Volatile MEMs in statement expressions and functions inlined as trees



On 16 Dec 2001, Gabriel Dos Reis wrote:
>
> No, you're on the wrong page.  That specific example is given in a
> specific context to disprove a specific (bogus) claim you made.

Ehh.. You posted that (again) in response to

	| If you override the assignment operator, then the rules of  assignment are
	| defined by _you_, not by the C++ standard.

and that is certainly not a bogus claim. You gave it as an example of
something completely different, namely the implicit copy-assignment
operator, which was not even under discussion.

And which, as I've pointed out, doesn't even _cover_ "volatile"
assignments. Exactly because "volatile" is always a property of an object
or function, never of a class (and the implicit copy-assignment comes from
the _class_, not the object).

> | There are no implicit volatile assignment operators, because there are no
> | volatile classes.
>
> That is nonsense.

No.

If there were a notion of a "volatile class X", then your example would be
valid. If so, your X() = x; thing would be a volatile access thanks to the
basic volatility of the class itself.

But because the "volatile" is not a property of the class in C++, your
example doesn't have any _relevance_ to the whole problem of whether the
value should be re-read after assignment or not.

That's my argument, and you calling it nonsense doesn't make it so.

And yes, I've read your precious "12.8.10". MY point, which you obviously
missed, is that if the "volatile" _could_ be part of the definition of the
class X, then the implicit assignment operator

	X& X::operator={const X&}

_would_ have relevance to the problem of volatile assignments (because the
"volatile" would be part of the definition of the class X itself).

But, since no notion of "volatile class" exists in C++, that implicit
assignment can never be relavant to this discussion.

See my argument?

In short, class assignments, _whether_ explicit or implicit, do not have
any relevance. THAT is my argument, and the fact that you've brought up
class assignments several times just shows that you're trying to muddy the
fundamental issue of whether a volatile value is reloaded at assignment.

Muddy it you do. But you have yet to find a single argument for ignoring
the ".. the value stored .." text in the standard.

		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]