x = 0; x += ++x + x++; x == 4?

[Christian Johannes Charbula]

Hi,

is this result defined by the standard?

I'm just in a small "fight" with some workmates on this topic. So an
answer from more involved people could help.

Regards,
Christian

 

[Victor Bazarov]

is this result defined by the standard?

No. The second statement contains the expression in which the rules
are broken. See the Standard, [expr]/4.

I'm just in a small "fight" with some workmates on this topic. So an
answer from more involved people could help.

Never fight your workmates. It's detrimental to your career.

V

 

[Andrey Tarasevich]

...
is this result defined by the standard?
...

It depends on what 'x' is.

If this is an object of user-defined type (a class), manipulated by user-defined
operators, constructors, conversion functions etc., then the result might be
perfectly defined. Although there's no way to say what the result of 'x == 4' is
without seeing the actual definitions.

Otherwise (for 'x' of type 'int', for example), the expression with all those
'+'s produces undefined behavior.

 

[Pete Becker]

If this is an object of user-defined type (a class), manipulated by
user-defined operators, constructors, conversion functions etc., then
the result might be perfectly defined.

In that case, it's unspecified. The two increment calls aren't ordered.

A more important question, though, is "who cares?" Is it really
worhwhile spending time talking about the hypothetical meaning of an
expression that should never appear in real-world code? Even under
Java's rules, where the result is well defined, the code is abominable.

 

[Johannes Bauer]

A more important question, though, is "who cares?" Is it really
worhwhile spending time talking about the hypothetical meaning of an
expression that should never appear in real-world code? Even under
Java's rules, where the result is well defined, the code is abominable.

Exactly, I fully second that. I do not understand at all why this exact
question comes up in this group (and in comp.lang.c, too, BTW) every few
days. Kind of annoying. You should think people have more important
problems.

Regards,
Johannes

 

[Victor Bazarov]

Exactly, I fully second that. I do not understand at all why this
exact question comes up in this group (and in comp.lang.c, too, BTW)
every few days. Kind of annoying. You should think people have more
important problems.

Aw, those grown-ups and their "more important problems"! When
will they understand? <g>

V

 

[Andrey Tarasevich]

In that case, it's unspecified. The two increment calls aren't ordered.
...

Yes, but the original question was not about the "behavior", but about
the "result". While the OP didn't specify what exactly he meant by
"result" (probably the result of 'x == 4' expression), for many natural
interpretations of the term it is possible to come up with operator
definitions, which will produce a well defined "result" even though the
overall "behavior" is not specified.

A more important question, though, is "who cares?"

Apparently the OP and his workmates do. Moreover, the only people who
shouldn't care are the people who are already past that stage in their
learning process. That's definitely not everybody.

Is it really worhwhile
> spending time talking about the hypothetical meaning of an expression
> that should never appear in real-world code?

True, but I don't see the connection. I have no reason to believe the
expressions in the subject line were taken from the real-world code, or
that anyone actually intended to use them in the real-world code.

 

[Johannes Bauer]

Aw, those grown-ups and their "more important problems"! When
will they understand? <g>

No, no, that's not how I meant it and from the grin I take it you
undertood me correctly. However, I believe that there are *dozens* of
really interesting, complex, real-world problems C++ provides - yet some
people get hung with totally arfificial problems which always boils down
to some definition in the standard - that's pretty boring

Regards,
Johannes

 

[Juha Nieminen]

is this result defined by the standard?

What result?

It's customary to write a complete question in the body of your post.
The subject line is only a short introduction to the contents of your
post, not the contents themselves. The post should be understandable
even without the subject line.

 

[James Kanze]

Yes, but the original question was not about the "behavior", but about
the "result". While the OP didn't specify what exactly he meant by
"result" (probably the result of 'x == 4' expression), for many natural
interpretations of the term it is possible to come up with operator
definitions, which will produce a well defined "result" even though the
overall "behavior" is not specified.

It's possible, but anyone who overloads the given operators with
definitions so that such a result is guaranteed should be hung
and shot. With any reasonable overloading of the operators (for
a user defined type for which such operators would make sense),
the result is unspecified.

 

[Andrey Tarasevich]

...

It's possible,

That's exactly what I said. It is possible.

but anyone who overloads the given operators with
definitions so that such a result is guaranteed should be hung
and shot.

Considering that this discussion is centered around what essentially is
a basic C++ _puzzle_, not a piece of real-life code, the above statement
is utterly irrelevant.

With any reasonable overloading of the operators (for
a user defined type for which such operators would make sense),
the result is unspecified.

This statement is based on some undefinable ideas of what "reasonable".
I'm pretty sure one can come up with a "reasonable" overload with
perfectly specified results, although I don't see the point.

 

[Kira Yamato]

Exactly, I fully second that. I do not understand at all why this exact
question comes up in this group (and in comp.lang.c, too, BTW) every few
days. Kind of annoying. You should think people have more important
problems.

It's called knowing your tools well. If you just don't know the
answer, then just say so or better yet just be quiet.

With a tool like C++ where you can write syntactically correct code but
with undefined behavior, it's good to know when you could be writing
such code or be reading such code from another programmer. And that is
exact what the OP asked: Is this code well-defined in C++?

Furthermore, the OP did not say this is production code. He did not
ask if this code is abominable or not. It is just an inquisition about
the rules of C++. So why shouldn't this question be raised in this
forum? Which forum should this post go where it won't be annoying?

 

[jason.cipriani]

It's called knowing your tools well. If you just don't know the
answer, then just say so or better yet just be quiet.

Exactly. And not only that, but these kinds of questions (aside from
being just plain interesting to some people, like me) can stem from
perfectly reasonable, real-world situations. Perhaps you come across a
bug in your code and narrow it down to some weird C++ problem; you
construct a minimal example just as you are supposed to, and you come
here and ask about it without giving background context. That's
another good reason for posting those kinds of questions here. It's
*exactly* the kind of topic that this newsgroup exists for.

 

[Pete Becker]

It's called knowing your tools well. If you just don't know the
answer, then just say so or better yet just be quiet.

If an apprentice carpenter asks whether he can use a hammer to drive in
a screw, he should be told "No." Speculating on whether it might or
might not work in some cases doesn't help him learn how to do his job.

 

[jason.cipriani]

If an apprentice carpenter asks whether he can use a hammer to drive in
a screw, he should be told "No." Speculating on whether it might or
might not work in some cases doesn't help him learn how to do his job.

I completely agree. The carpenter should answer his question. The
friendly carpenter may even want to have a discussion about it. The
carpenter should *not* say "who cares?". And in any case, both
apprentice and carpenter would raise an eyebrow at and then disregard
the comment of a third guy who walked in the room out of nowhere and
said "why are you two talking about this?".

Unless you meant something else by your metaphor?

 

[Kira Yamato]

If an apprentice carpenter asks whether he can use a hammer to drive in
a screw, he should be told "No." Speculating on whether it might or
might not work in some cases doesn't help him learn how to do his job.

Are you kidding me? It is in the speculation of various scenarios that
we explore and learn the limits and strengths of our tools.

 

[jason.cipriani]

Are you kidding me? It is in the speculation of various scenarios that
we explore and learn the limits and strengths of our tools.

No, Pete is absolutely correct. There's no point in learning more
about your tools, or having interesting discussions about them. You
should just use them without question and get the job done without
thinking. Just don't hire "Versatile Coding" to do anything for you if
you need anything more than a typing grunt.

 

[jason.cipriani]

No, Pete is absolutely correct. There's no point in learning more
about your tools, or having interesting discussions about them. You
should just use them without question and get the job done without
thinking. Just don't hire "Versatile Coding" to do anything for you if
you need anything more than a typing grunt.

Apologies, Pete. That was uncalled for -- I meant "Roundhouse
Consulting".

 

[Andrey Tarasevich]

If an apprentice carpenter asks whether he can use a hammer to drive in
a screw, he should be told "No." Speculating on whether it might or
might not work in some cases doesn't help him learn how to do his job.

This is only true if you the carpenter deliberately tries to restrain
the apprentice's development in order to freeze him at the "apprentice"
stage forever.

 

[Pete Becker]

I completely agree. The carpenter should answer his question. The
friendly carpenter may even want to have a discussion about it.

Interesting. You "completely agree" with something I clearly didn't say.

The
carpenter should *not* say "who cares?". And in any case, both
apprentice and carpenter would raise an eyebrow at and then disregard
the comment of a third guy who walked in the room out of nowhere and
said "why are you two talking about this?".

Unless you meant something else by your metaphor?

I meant just what I said. "No" is all that needs to be said, although
in a suitable setting it can be accompanied by laughter.

Unreadable code is unreadable code, regardless of whether its effect is
well defined.