Is it true?

Is it true?

Assuming "C++" does not overflow.

Other urls found in this thread:

open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf
youtu.be/yG1OZ69H_-o
en.cppreference.com/w/c/language/operator_precedence
twitter.com/NSFWRedditImage

C == C

That's undefined behaviour, idiot.

Undefined

yfw that's undefined on purpose so c and c++ wouldn't be comparable

Bad naming convention.

Comparison is done, then post-increment. So it's false because C == C

C++ is basically C+=1
So you have b=(c+=1)>c

undefined constant dumb ass

False because:
Post increment, increment happens only on next line.
The variable C is mutable meaning even if it was pre-increment, the value it's comparing to would have the same value.

Undefined behaviour

How is it undefined?
Isn't it
>load C
>increment C
>compare to C (which is now bigger)
>false

`>` is a binary operator which takes two expressions. Those expressions can be evaluated in either order. So the compiler may evaluate the expression `C++` to a value, then the expression `C` to a value, then the whole thing (expr1) > (expr2) and store the result in b, or it could evaluate them in the other order.

Ah I see. I'm surprised it can evaluates both way though. Do you mean some compilers do it one way, others the other way, or is it random within the same compiler? Seems like left first, right second is the most intuitive way to go.

That's a post increment operator, so it would evaluate to false. they would be equal.

I'm pretty sure the value of c is not incremented until after that expression has been evaluated. So there would be no undefined behavior. This differs from a ++c which would increment thhe value of c before evaluating the expression.

But the order doesn't matter.
If C=x then you either have x > x or x > x+1, it's false in either case

open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

In those examples the order matters.
In OP's it doesn't.

>If a side effect on a scalar object is unsequenced relative to [...] a value computation using the value of the same scalar object, the behavior is undefined.
>There is no sequence point between the arguments of

In C and C++, this is undefined behavior.

>Do you mean some compilers do it one way, others the other way, or is it random within the same compiler?
According to the C specification, the compiler can do absolutely anything with this piece of code. It can interpret the statement as true, or as false, or as true on wednesday and false on thursday; or it can blow up in your face, or wipe your harddisk. Anything at all can happen. According to the specification this code is just Wrong and the compiler is at liberty to do whatever it damn well likes.

No, you do NOT reliably get an error message if you write this. This particular line is unambiguously Wrong, but there are more subtle cases that are Wrong without the compiler being able to detect it.

In practice, most compilers make a mess of a statement like this in a particular predictable way -- but one that varies with the compiler, and the version, and the architecture, and who knows what else. Meaning that in practice, your code will do something unexpected if you write this, unless you restrict yourself to a particular compiler and operating system and compiler version and phase of the moon and all that crap.

The undefined behavior doesn't effect the result though, therefore it doesn't matter for OP's question.

>The undefined behavior doesn't effect the result though
You don't seem to understand the implications of undefined behaviour.
The program is invalid. The compiler is under no obligations to do anything. Any and all output is completely meaningless.

People sure are trying to dodge the question in this thread.

What does your compiler say the result is?

>What does your compiler say the result is?
My theoretical C compiler deleted my home directory.

Even if the behavior was defined in order, ++ increments but returns the value before the increment. So c++==c in that expression. So b is false.

>undefined behavior this
>undefined behavior that
>undefined behavior everything
>everything you do on C/C++ is undefined behavior, nothing is guaranteed to work
What a shitty language.

>Is it true?
why not just run the fucking code and find out

>A Makifag is retarded
What a surprise. You're basically the frogposters of anime at this point.

All of you theory fags can suck your mothers' theoretical cock.

In any reasonable implementation, there are only three possibilities, either the expressions are evaluated in order or out of order. In the first case you get C > C + 1 which is false, or in the second case you get C > C which is still false. Or the compiler decides to error out.

Undefined behavior is approaching the 'its random' more and more. Mostly for these the undefined behavior still give you a consistent result situation to situation. But there's many cases where compiler writers can optimise your code more aggressively using the fact that they can do what they want in the UB cases.
youtu.be/yG1OZ69H_-o
This is a good video to watch to understand it. He starts off being upset at jokes on twitter, which doesn't show him in the greatest light but what he says later is good.

>being this buttblasted trying to defend a shitty language
Don't worry user, that's why Java/C#/Rust exists.

I identify as Japanese so I've rewritten my compiler to evaluate from right to left. It also prematurely evaluates when performing unary operations in its mother's basement.

>Theory
This isn't some fluff shit. Undefined behaviour has real consequences and if you ignore it, you are a terrible programmer and should probably just kill yourself now.
Compiler optimisers are VERY aggressive. They will exploit the shit out of all sorts of undefined behaviour, even if it goes against what you think it might do, because it's allowed to do that.

While this is very true, interestingly, I can't think of any convincing scenario whereby a compiler not *actually* out to mess with you could innocently optimize OP's expression to true. (It might manage to not increment C, though.)

Can you think of any? Note that this does not in any way contradict your point.

>he is still trying to dodge

The guys saying undefined behavior are right, so technically the compiler can do anything.

However, I can't think of a sane compiler evaluating as anything other than false.

#include

int main()
{
int a = 1;
int b = a++ > a;
int c = a++ < a;
int d = ++a > a;
int e = ++a < a;

printf("%d\n", b);
printf("%d\n", c);
printf("%d\n", d);
printf("%d\n", e);
}
GCC and Clang output:
0
1
0
0
Those are some pretty stupid results, if you ask me, especially c and e.

I'll give you another example that defies expectations:
#include

int main()
{
int a;
int *b = &a;

printf("%d\n", a);
printf("%d\n", a);
printf("%d\n", a);
printf("%d\n", a);
printf("%d\n", a);
}
Compile with clang -O3. Funnily enough, this technically isn't undefined behaviour.

It's pretty obviously false you faggots. Jesus.

What are you talking about?
All this results make perfect sense

...

int b = a++ > a; //1 > 2 -> 0
int c = a++ < a; // 2 < 3 -> 1
int d = ++a > a; // 4 > 4 -> 0
int e = ++a < a; // 5 < 5 -> 0

Are you sure you're not just dumb?

error derp.cpp (1): 'C': unidentified declarifier

But the undefined behaviour doesn't apply here as it is a post increment operator. Is c > c undefined

>But the undefined behaviour doesn't apply here as it is a post increment operator
It's an operator with a side effect, so / applies.

you want to bring sequence points into this, but that doesn't apply here.

C increases after the bool which means it will be false.

if you write bool b = c++ == c the boolean is also false

C is not defined.

someone post the javascript string, number expressions example and then we can talk about shitty behauvior

C++ is post-increment. So you get the old value.

>Rust
>"undefined behaviour sucks"
>oh, but every meaningful program is unsafe so we provide no guarantees

kys fgt

> 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.

It's undefined behavior because of this second clause. The prior value of C is used both to calculate the new value (incrementing) and to evaluate the relational operator >.

Unless you wanna be a language lawyer just don't mix side effects with pure code. It's just asking for trouble.

No, it's the other way arround:
c++ < c;


1) C returns it's old value then it gets incremented.
2) In the second step the "old" value gets compared to the "new" value of C.

You can just remeber it like this:
C is better than C++.

Here is an example:

#include

int main()
{
int i = 2;
int b = (i++ < i);

if (b) puts("yes");
}

I just compiled the C code and I get different results.

All of them print 0.

How do fuck do you get 1 when you print c
Did you fake one of these results?

The magic of undefined behaviour.

I suppose I'll attach an image just to show that I'm not making shit up.

Interesting..

Yes but isn't the order in which the left and right sides of the > are evaluated undefined?

>ITT: shit that you won't use in real life

Actually not.

Yuo get undefined behaviour, when two operations have the same precedence, because you can't tell the evaluation order, i.e.:

i = ++i + i++;

But when there's a differnce in the evaluation order, it should not be undefined.
>en.cppreference.com/w/c/language/operator_precedence

But apparently it depends on the implementation:
HE

Really now. I use C all the time and this shit is relevant. Though I generally avoid it without issue.

Only in reasonable languages.
In C, it is not defined what this should do, so different implementations will yield different results.