Volatile MEMs in statement expressions and functions inlined as trees

Linus Torvalds torvalds@transmeta.com
Sat Dec 15 11:22:00 GMT 2001


On 15 Dec 2001, Gabriel Dos Reis wrote:
> | > Hmm...  How do you add class assignment operators into this picture?
> |
> | Uhh.. You cannot. It doesn't apply.
>
> Aha, you're creating ad hoc rules because your theory doesn't scale and
> doesn't match C++ rules.

I read Alexandre to talk about overloading - that was what he did in his
example, after all (in my reply I cut it from the post - but go back and
read the original, as you obviously don't believe anything I say).

And I did _not_ make up any rules. In fact, the very first note in clause
5 explicitly says that the standard assignment rules simply do not _apply_
except from a syntactic viewpoint when the assignment operator has been
overloaded.

> | If you override the assignment operator, then the rules of assignment are
> | defined by _you_, not by the C++ standard.
>
> The implicitly generated copy and assignment operator is defined by
> the C++ standard.  Again consider:
>
> 	struct X { };

You showed this example once before, and I didn't even bother to reply to
it, because you clearly do not even understand what "volatile" means.

For a non-volatile object, IT DOES NOT MATTER whether you re-load the
value or not. Right? We've told the compiler that it is non-volatile, and
the compiler can freely access the object etc, and assume that the object
stays the same - at which point the discussion whether assignment re-loads
or not is a non-issue.

Do we have agreement on that? On non-volatile objects, accesses to the
object is entirely optimizable as long as you don't change the semantics.

(And if the object actually _does_ change under you, that's not the
compilers fault any more, that's YOUR fault for not telling the compiler).

Now, try your "proof" with a volatile object, and guess what? You can't.

There are no implicit volatile assignment operators, because there are no
volatile classes. You will get something like

	In function `int foo ()':
	no match for `volatile X & = volatile X &'
	candidates are: X &X::operator= (const X &)

Note? The implicit assignment operator is of type X, _not_ of type
"volatile X".

In short, Gabriel, you do not have a leg to stand on.

Every SINGLE one of your arguments has been totally bogus. I've refuted
them all, and I've pointed to the letter of the standard that says that
you are WRONG.

What does it take to make you admit that you are wrong?

> Nobody has argued against that, because that is not the issue under
> discussion.  The issue under discussion is whether the result is an
> lvalue or not, and the C++ standard says it is.

No, that's not the issue.

EVERYBODY agrees that the standard says that the result is an lvalue. I
agree, you agree, and Alexandre agrees. It says so clearly in the
standard.

The _issue_ is that the standard _also_ says clearly that not only is the
result an lvalue, it is _also_ "the value stored".

THAT is the issue. You don't understand the meaning of it, and you don't
like it. So you try to ignore it, and argue against it.

While I say that it actually has well-defined and clear meaning, and means
exactly what it says: "the result is the value stored", so if you store 10
to an object (that can hold the value), comparing that store with 10
_must_ compare as true.

The standard says:

 - the result is of the same type as the left side:

	assert (typeof (E1 = E2) == typeof(E1))
					// Yeah, I know this isn't C++
					// but you get the idea.

 - the result of an assignment is the value stored

	assert ((E1 = E2) == E2)	// where "E2" contains the implicit
					// type conversions implied by the
					// store into E1

 - the result is an lvalue

	assert: "you can use "E1 = E2" in all places that require lvalues"

	ie all of

		"(E1 = E2) = E3"
		"(E1 = E2)++"
		"&(E1 = E2)"
		...

	are syntactically well-formed expressions.

Nobody is disagreeing on the first and the last. You and Alexandre are
trying to avoid the middle requirement, even though it's clearly stated in
the standard.

			Linus




More information about the Gcc-patches mailing list