Is it true? Assuming "C++" does not overflow.

C == C

>>59727691
That's undefined behaviour, idiot.

>>59727691
Undefined

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

Bad naming convention.

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

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

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

>>59727691
Undefined behaviour

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

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

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

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

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

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

File: Screen Shot 2017-04-04 at 16.17.41.png (278KB, 1170x1769px) Image search: [Google]

278KB, 1170x1769px

>>59729024
>>59729130
>>59729192
>>59729349
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

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

>>59729537
>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 <
It doesn't matter: it's undefined. Compilers will point that out, as well.

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

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

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

>>59729658
>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?

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

File: 1478667262903.jpg (18KB, 336x336px) Image search: [Google]

18KB, 336x336px

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

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

File: 1452471092796.png (372KB, 1280x720px) Image search: [Google]

372KB, 1280x720px

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

>>59729130
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.
https://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.

File: 1459129080904.png (343KB, 671x1047px) Image search: [Google]

343KB, 671x1047px

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

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

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

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

>>59729748
>he is still trying to dodge

>>59727691

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.

>>59730020

#include <stdio.h>

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

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.

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

>>59730188

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?

>>59727691

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

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

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

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

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

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

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

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

kys fgt

>>59727691

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

>>59727691

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

>>59732972

Here is an example:

#include <stdio.h>

int main()
{
  int i = 2; 
  int b = (i++ < i);
  
  if (b) puts("yes");    
}

>>59730188

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

All of them print 0.

File: results.png (8KB, 292x434px) Image search: [Google]

8KB, 292x434px

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

>>59733386
>>59733557
The magic of undefined behaviour.

File: 2017-04-04-235725_644x388_scrot.png (10KB, 644x388px) Image search: [Google]

10KB, 644x388px

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

File: cool.png (11KB, 319x436px) Image search: [Google]

11KB, 319x436px

>>59733574
Interesting..

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

>>59733604

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.
>http://en.cppreference.com/w/c/language/operator_precedence

But apparently it depends on the implementation:
>>59733557

>>59733557

HE

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

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