Evaluation sequence and precedence

[Victor Bazarov]

You seemed to suggest that the order of the source code was
irrelevant, sequence points or no sequence points.

Oh?... No, I could suggest no such thing. Nobody in their right
mind could suggest that, as a matter of fact. So, I take it you
must have thought I'd gone mad or something.

I think the fact of the matter here is that no proper explanation has
shown up until Peter commented. Sequence points *are* well defined,
and in their presence, the code *is* interpreted in a certain order.

Uh... Unless some things are still unspecified, like the order of
the argument evaluation, which makes things, well, *UNcertain*.

I
can't see a single person addressing the question "Am I wrong to
assume that the call expands to f.operator++(int).operator=(...)", the
answer to which would have made all the difference.

Huh? I believe I would need a bottle of vodka to understand that
sentence... Let me try... The call doesn't expand to that, but such
expressions would be equivalent, AFAICT. And, I am a single person,
who just addressed that question. But you couldn't see a single
person addressing it. Okay... But you think that the answer would
"have made all the difference". Knowing what you know now, does it?
I mean, does the answer that "no, it doesn't expand to that" make
any difference?

An evaluation such as "operator=(foo(), bar)" is something entirely
different from "foo().operator=(), bar";

Yes... But what does it have to do with the case at hand?

so the interesting piece of
information was: *is* operator= evaluated as if global, or the member
overload that it is? That has been addressed. Now the followup is:
where is this behavior defined?

In the Standard, I guess. It's not really spelled out the way you
think it might be (or you seem to think it might be).

V

 

[Old Wolf]

Note, the code in question was:
f++ = ++f;
where 'f' is an object of a type that has a member
operator= that takes a reference to another object
of the same type.

But as I asked initially, doesn't this (with even an overloaded
assignment operator) boil down to f.operator++
(int).operator=(f2.operator++()) ?

Yes. The behaviour is unspecified (not undefined),
and the two operator++ functions could be called
in either order.

 

[Old Wolf]

operator=(f.operator++(int),f.operator++())

That is a function taking two parameters. There is no rules as to in
what order parameters of a function are evaluated, so the compiler
might evaluate the first parameter first or - as in your case - the
second parameter first. It might even evaluate part the two parameters
intertwened.

There is a sequence point before and after each
function call, so the two parts cannot be interleaved.
(Notwithstanding the as-if rule).