Andy Sawyer schrieb:

> In article <3DB920C7.9327FD0E@unet.univie.ac.at>,
>  on Fri, 25 Oct 2002 15:27:02 +0000 (UTC),
>  a9804814@unet.univie.ac.at (Thomas Mang) wrote:
>
> > From a very theoretical point of view, NOTHING in C++ is defined. I
> > will not explain this further, as we are entering here mainly a
> > philosophical field, and off-topic in this group. I do not expect
> > anyone of you to agree on this (indeed, I expect noone to agree), so
> > please don't cry all. Save your time.
>
> You expect no-one to agree with your factually incorrect statement?
> How surprising (It's surprising because there _are_ readers of this
> group who seem to think factually incorrect statements are legitmate
> teaching methods...)

Hmm, I really don't know to which statement you refer here. If you refer to
the statement above, the only thing I have to say is that I truely believe
you are definitely not in a position to tell me this statement (which
reflects, taking into account philosophical aspects, my very personal opinion
about the standardization of anything) to be "factually incorrect". As
written, I do not expect you to agree on it, but nevertheless you mustn't
judge _my opinion_ as  incorrect.
That's the same as asking you about your religion and than claiming it to be
definitely the wrong one.


If you refer to the operand-evaluation order of my original answer, here is a
more detailed explanation:

a) as there is no sequence point between the read and write of the variable,
the statement from the OP is , as the standard says, undefined (yields
undefined behavior). (section 6.3 and others)

b) for me, undefined behavior is probably not what most of you (or the
standard) consider undefined, so here is most likely the point of our
confusion.
This is my fault, I should have assumed all of you interpreting "undefined
behavior" as the standard says, meaning to be virtually anything.

Which does not hold true in reality, because not virtually anything will
happen. I don't think writing such a statement will break the fundamental
laws of physics, cause the dinosaurs to reappear or whatsoever. (This isn't
100% sarcastic; the standard doesn't guarantee this not to happen. I dare to
say this (and much less exciting stuff) is guaranteed not to happen, no
matter how many ill-formed code you write).


So basically, for me there exist 3 versions of code:

1) right - formed: produces the expected behavior (might include
implementation defined behavior; thus not necessariliy 100 % portable.
Nevertheless, defined for a given implementation).

2) completely ill - formed: no plausible expectations on the result are
possible (e.g. dereferencing the null - pointer and casting this result to
whatever type).

3) ill - formed, but there are plausible expectations regarding the result.


Nevertheless, the world isn't just black or white or 0 and 1.
And although the standard treats C++ as something like black or white, I
think it's important not to forget what's between these extremes, because
there _is_ something between 'em.


Let me emphasize that all these statements are a matter of personal taste.
What is plausible, what isn't ? When is a result completely undefined, when
not compeletely defined? Or is not completely defined the same as undefined ?

What's plausible for me doens't have to be plausible for you.........

For good reasons, such statements do not appear in a standard.
But they do appear (and are an issue) in the real world.



And now the point:

For me, both 8 or 9 are plausible results for the statement presented by the
OP.
They are (again, for me) equally plausible because the operand-evaluation
order is not defined.
Operand-evaluation order is (and again, for me) plausible to have the most
significant impact on the effect of the evaluation of the statements, both
during compile-time and run-time.
It's plausible (yes, you guessed it, just for me) to tell this. (If I am not
allowed to do so in this newsgroup (meaning not having full support by the
wording of the standard), just tell me, and I'll never do it again.)


Maybe my post sounded somewhat like "the only one problem is undefined
operand-evaluation order". This is not true, and I apologize if it did.
But undefined operand-evaluation order is a plausible source of trouble for
the given statement (unlike in other programming languages, where the whole
statement is defined and valid).

BTW, ever seen code that isn't defined by the standard, but nevertheless
"properly working" in our real  not-only-black-or-white world (e.g. overflow,
underflow, assumptions about sizes of objects / built-in types) ?

When writing new code, one should certainly care about it whenever possible.
But if you refuse code where such assumptions appear, you end up with very
FEW code to reuse.


cheers,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3DBB3D2C.A4959E07@unet.univie.ac.at>,
 on Mon, 28 Oct 2002 18:10:52 +0000 (UTC),
 a9804814@unet.univie.ac.at (Thomas Mang) wrote:

> Andy Sawyer schrieb:
>
> > In article <3DB920C7.9327FD0E@unet.univie.ac.at>,
> >  on Fri, 25 Oct 2002 15:27:02 +0000 (UTC),
> >  a9804814@unet.univie.ac.at (Thomas Mang) wrote:
> >
> > > From a very theoretical point of view, NOTHING in C++ is defined. I
> > > will not explain this further, as we are entering here mainly a
> > > philosophical field, and off-topic in this group. I do not expect
> > > anyone of you to agree on this (indeed, I expect noone to agree), so
> > > please don't cry all. Save your time.
> >
> > You expect no-one to agree with your factually incorrect statement?
> > How surprising (It's surprising because there _are_ readers of this
> > group who seem to think factually incorrect statements are legitmate
> > teaching methods...)
>
> Hmm, I really don't know to which statement you refer here.

The one that I quoted - "NOTHING in C++ is defined" (that's why I
quoted it). Your statement is clearly untrue.

"Please don't cry, save your time".

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello.

I've being in a long discussion with friend of mine how to define the
result of this expression (see the subject). I have no access to C++
standard documents so we have no eligible source for foundation. In
C++ if we have 'int x = 5;' the result of this expression is 8. I have
tried this in other environments like Java, Flash and JavaScript and
the result there is 9.

So we are "arguing" if this is an operator precedence issue or
something else. I didn't agree this is operator precedence issue
because:

(x) + (--x)

would evaluate the same result. Also the operator precedence is
defined the same (AFAIK) in the other environments I've tried with.

Could someone put some light on this case?

--
Stanimir

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Stanimir Stamenkov" <stanio@gbg.bg> wrote in message news:cd2bb053.0210211444.144e17ae@posting.google.com...
> Hello.
>
> I've being in a long discussion with friend of mine how to define the
> result of this expression (see the subject). I have no access to C++
> standard documents so we have no eligible source for foundation.

You might try reading the FAQ, it is surely there.

>  In
> C++ if we have 'int x = 5;' the result of this expression is 8. I have
> tried this in other environments like Java, Flash and JavaScript and
> the result there is 9.

The behavior is not defined.   Anything might happen.   You can not
modify a variable and expect to read it's value (for other than the purposes
of the modification).



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stanimir Stamenkov wrote:
> (x) + (--x)

In C and C++, this results in undefined behavior.
It is well defined in Java.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stanimir Stamenkov schrieb:

> Hello.
>
> I've being in a long discussion with friend of mine how to define the
> result of this expression (see the subject). I have no access to C++
> standard documents so we have no eligible source for foundation. In
> C++ if we have 'int x = 5;' the result of this expression is 8. I have
> tried this in other environments like Java, Flash and JavaScript and
> the result there is 9.

On your C++ implementation, it is 8. But there is no guarantee it will be 8
tomorrow, or on another compiler, or.....

C++ does not define the order in which operands are evaluated.
So there are 2 possibilities to evaluate this expression:


int x = 5;

int y = x + (--x);

A)
    The left-hand-operand is evaluated first. This is 5. Then the
right-hand-operand evaluates to 4. 5+4 = 9.

B) The right-hand-operand is evaluated first, it's 4. The left-hand-operand
is evaluated , it's 4 too. 4+4 = 8


You have to rewrite your code to be sure what value is evaluated, everything
else is sort of random-number generator.



best regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stanimir Stamenkov wrote:

> So we are "arguing" if this is an operator precedence issue or
> something else. I didn't agree this is operator precedence issue
> because:
>
> (x) + (--x)
>
> would evaluate the same result. Also the operator precedence is
> defined the same (AFAIK) in the other environments I've tried with.
>
> Could someone put some light on this case?

 First, this is not an operator precedence issue. It is obvious that the
addition has to take place after the '--x' is evaluated because
otherwise you wouldn't know what to add.

 Some have suggested that it's an order of evaluation issue. That is,
you get different results if you evaluate the left side of the addition
before the right side of the addition versus evaluating them in the
other order. This isn't true either. Nothing in the C++ standard
prevents an implementation from evaluating both sides concurrently or
doing something totally different from either of these two approaches.

 The issue is really this simple. Your expression contains a term that
modifies the value of x, '(--x)'. Your expression also contains a term
that reads the value of x, '(x)'. Your expression contains no sequence
point between these two terms. This arrangement is undefined.

 "Between the previous and next sequence point an object shall have its
stored value modified at most once by the evaluation of an expression.
Furthermore, the prior value shall be accessed only to determine the
value to be stored."

 Period. End of story.

 The *reason* it's undefined is really not important. What's important
is that it *is* undefined, and hence you could get any result at all.

 DS

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 22 Oct 2002 20:34:32 +0000 (UTC), a9804814@unet.univie.ac.at
(Thomas Mang) wrote in comp.std.c++:

>
>
> Stanimir Stamenkov schrieb:
>
> > Hello.
> >
> > I've being in a long discussion with friend of mine how to define the
> > result of this expression (see the subject). I have no access to C++
> > standard documents so we have no eligible source for foundation. In
> > C++ if we have 'int x = 5;' the result of this expression is 8. I have
> > tried this in other environments like Java, Flash and JavaScript and
> > the result there is 9.
>
> On your C++ implementation, it is 8. But there is no guarantee it will be 8
> tomorrow, or on another compiler, or.....
>
> C++ does not define the order in which operands are evaluated.
> So there are 2 possibilities to evaluate this expression:
>
>
> int x = 5;
>
> int y = x + (--x);
>
> A)
>     The left-hand-operand is evaluated first. This is 5. Then the
> right-hand-operand evaluates to 4. 5+4 = 9.
>
> B) The right-hand-operand is evaluated first, it's 4. The left-hand-operand
> is evaluated , it's 4 too. 4+4 = 8

 [snip]

There is no guarantee that either of these evaluation paths is taken
by an implementation.  There is no requirement that any value at all
be stored in y the program may terminate, or even refuse to compile in
the first place.  If a value is indeed stored into y and the program
continues to execute, a value of 42 in y is just as correct or
incorrect as 8 or 9.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
>
> There is no guarantee that either of these evaluation paths is taken
> by an implementation.  There is no requirement that any value at all
> be stored in y the program may terminate, or even refuse to compile in
> the first place.  If a value is indeed stored into y and the program
> continues to execute, a value of 42 in y is just as correct or
> incorrect as 8 or 9.

That's what I wanted to express by saying random-number generator :-)

In practice though, I think the expression will most likely evaluate to 8 or 9
(affected by operand -evaluation order).

I wonder if there is any implementation out today which produces neither 8, nor 9
?
(Certainly, this doesn't mean the next version will produce 8 or 9. Just for
interest)


cheeers,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thomas Mang wrote:
>>
>>There is no guarantee that either of these evaluation paths is taken
>>by an implementation.  There is no requirement that any value at all
>>be stored in y the program may terminate, or even refuse to compile in
>>the first place.  If a value is indeed stored into y and the program
>>continues to execute, a value of 42 in y is just as correct or
>>incorrect as 8 or 9.
>
>
> That's what I wanted to express by saying random-number generator :-)

Random number generators normally produce an unspecified but valid
value. They don't usually have the option of formatting your hard disk.

There are no sequence points in the expression "x + (--x)". The value is
read twice, once to determine the left operand of '+', and once to
determine the only operand of the '--', in order x to determine the
value that will be stored in x by that sub-expression.

6.5p2 says "Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluations of an
expression. Furthermore, the prior value shall be read only to determine
the value to be stored." The standard does not define the behavior when
this rule is violated, so literally anything can happen.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

a9804814@unet.univie.ac.at (Thomas Mang) wrote
> In practice though, I think the expression will most likely evaluate to 8 or 9
> (affected by operand -evaluation order).
>
> I wonder if there is any implementation out today which produces
> neither 8, nor 9?
> (Certainly, this doesn't mean the next version will produce 8 or 9.
> Just for interest)

You are attempting to explain undefined behavior. Please don't.
Once an expression is defined, everything about it is undefined.
As some people often say, now that you've invoked UB it could
launch a missile or format your disk. This may be unlikely, but
nothing in the standard prohibits it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> >
> > I wonder if there is any implementation out today which produces
> > neither 8, nor 9?
> > (Certainly, this doesn't mean the next version will produce 8 or 9.
> > Just for interest)
>
> You are attempting to explain undefined behavior. Please don't.
> Once an expression is defined, everything about it is undefined.
> As some people often say, now that you've invoked UB it could
> launch a missile or format your disk. This may be unlikely, but
> nothing in the standard prohibits it.

>From a very theoretical point of view, NOTHING in C++ is defined. I will not explain
this further, as we are entering here mainly a philosophical field, and off-topic in
this group. I do not expect anyone of you to agree on this (indeed, I expect noone
to agree), so please don't cry all. Save your time.

Just saying it is "undefined behavior" is true if you interpret the standard word by
word as it is. However, go away from the holy standard to the real world and try out
the example above on all platforms and compilers available.
I bet statistics is on my side:  the result of this expression will be much more
often assigning 8 or 9 to the l-value (without corrupting side effects) than the
launch of a missile, a change of the universal gravity-constant, or a time travel
back to ancient Egypt.
And though the "real" result is not known and might vary, everything showing a
statistical pattern is not what I'd call "undefined", because the statistical
pattern itself provides some sort of definition.

By the way, have you ever encountered cases where code clearly defined by the
standard does not behave as expected? I dare to say 'YES'.

The pragmatic answer (we live in a pragmatic and not theoretical world, where the
standard lives) for the result the OP had encountered is !!most likely!!
operand-evaluation order. Maybe I haven't made clear in my post that there are
certainly other possibilities to happen, other than 8 or 9. There are, certainly.


best regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ron@sensor.com ("Ron Natalie") wrote in message
news:<Meet9.241102$nE3.102400@atlpnn01.usenetserver.com>...
> "Stanimir Stamenkov" <stanio@gbg.bg> wrote in message
> news:cd2bb053.0210211444.144e17ae@posting.google.com...

> > I've being in a long discussion with friend of mine how to define
> > the result of this expression (see the subject). I have no access to
> > C++ standard documents so we have no eligible source for foundation.

> You might try reading the FAQ, it is surely there.

In the C FAQ, at any rate.  I don't think it is present in the C++ FAQ.

In practice, most of tme material in the C FAQ is also relevant to C++.
And the C++ FAQ normally doesn't repeat any of this material.  So the
rule is that you have to read both.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3DB920C7.9327FD0E@unet.univie.ac.at>,
 on Fri, 25 Oct 2002 15:27:02 +0000 (UTC),
 a9804814@unet.univie.ac.at (Thomas Mang) wrote:

> From a very theoretical point of view, NOTHING in C++ is defined. I
> will not explain this further, as we are entering here mainly a
> philosophical field, and off-topic in this group. I do not expect
> anyone of you to agree on this (indeed, I expect noone to agree), so
> please don't cry all. Save your time.

You expect no-one to agree with your factually incorrect statement?
How surprising (It's surprising because there _are_ readers of this
group who seem to think factually incorrect statements are legitmate
teaching methods...)

> By the way, have you ever encountered cases where code clearly
> defined by the standard does not behave as expected? I dare to say
> 'YES'.

Not with a confrming implementation, no.

> The pragmatic answer (we live in a pragmatic and not theoretical
> world, where the standard lives) for the result the OP had
> encountered is !!most likely!!  operand-evaluation order. Maybe I
> haven't made clear in my post that there are certainly other
> possibilities to happen, other than 8 or 9. There are, certainly.

So what _was_ your point?

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]