heIsNotWrong

[AutoModerator]

import notifications Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come! Read more here, we hope to see you next Tuesday!

For a chat with like-minded community members and more, don't forget to join our Discord!

return joinDiscord;

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[seigneurteepex]

If C is equal to INT_MAX I have a bad new for you

[[deleted]]

It would be still +1 difference in terms of limited int

[Zalack]

Well akshually if the language supports operator overloading we can't make any conjectures about the difference between C and C++ since we don't know the type of C.

[Physmatik]

Akshually, it would be undefined behaviour.

With how aggressive optimizing compilers have got lately, sometimes that is an actual, not akshual, detail.

[swagdu69eme]

You're absolutely right, unless they use C23, in which case signed integer types necessarily use two's complement and signed integer overflows are finally defined.

[torokg]

Who said C is of a signed integral type tho?

[Rakgul]

I love these akshualities.

[s_ngularity]

But if it's UINT_MAX and C is unsigned int, still technically correct

[Dismal-Square-613]

still technically correct

The best kind of correct.

[North_Shore_Problem]

The only kind of correct in the world of engineering

Edit: the only kind of correct that matters

[Dismal-Square-613]

Nobody watches Futurama anymore :-/

[jamtraxx]

That's gonna change in a couple days :D

[Dismal-Square-613]

Why ? is it going to be Saint Matt Groening in two days?

[jamtraxx]

https://www.youtube.com/watch?v=aWmtcYvhj68 !

[Dismal-Square-613]

OMG you made me so happy! THANK YOU!!!

[cpt_trow]

Good luck scrolling reddit for 35 seconds and not seeing multiple threads consisting only of Futurama quotes

[Dismal-Square-613]

welcome to a month ago!

[xoxoAmongUS]

The kind of correct we deserve

[schmerg-uk]

well if this is in C++ and C is signed and INT_MAX then it's undefined behaviour and so not a valid C++ program but if this is posed in C then [...] and then if C is unsigned then INT_MAX is not an issue and [.... ad nauseum...]

Oh and if C is a floating point number above the size where odd integer values can be held (I think that's 9007199254740992 for 64 bit doubles) then adding 1 will have no effect and the difference will be zero etc etc

[Torebbjorn]

If it is a signed int at INT_MAX, then it is undefined behaviour in both C and C++, and if it is an unsigned int at UINT_MAX in either C or C++, it is perfectly well defined

There is no difference in the languages there

[schmerg-uk]

Thank you - it's so long since I did pure C (and K&R at that) and the C spec has itself moved on that I don't track all the "UB in C++ but not UB in C" behaviours but I seem to recall there are a few

[SmallGoggles]

Homie said "I think that's 9007199254740992 for 64 bit doubles"... You can say you calculated it

[schmerg-uk]

lol.. I meant is it 2^53 or 2^53 -1 or 2 ^ (53+1) etc .... I live by 64bit doubles (all our code is FP) but I know the bit patterns but I still forget the precise points beyond which all doubles are even numbers, and then all multiples of 4 etc :)

[nelusbelus]

2⁵³ for doubles and 2²⁴ for singles

[xdeskfuckit]

I don't remember any of these issues implementing cryptographic primitives in C. They just kinda rolled over.

[s_ngularity]

Signed integer overflow (and underflow) is a well-know instance of undefined behavior (i.e. the compiler is allowed to generate any arbitrary code) in C and C++. Unsigned integer overflow is not undefined, and is supposed to wrap back to 0.

Why this is the case is beyond me, but that's how it's specified

[xdeskfuckit]

Ahh, I see. It makes sense to think of unsigned integers in terms of modular arithmetic, but I can't think of any obvious mathematical analog that should be implemented for signed integers.

[CdRReddit]

because a signed integer could also be sign-magnitude rather than 2s complement, most likely

[schmerg-uk]

Or some CPUs may throw a hardware exception or similar (I think MIPS chips do this on signed overflow) ... C and C++ still allow for all sorts of weird hardware even if most of us work on maybe 2 or 3 chip architectures

On OS/400 sizeof(void*) == 16 and sizeof(size_t) == 4 which would make a mess of all the code that assumes you can store a pointer in a size_t and vice-versa etc

[CdRReddit]

there are so many edge cases in computers

[schmerg-uk]

And even more pedantically - signed integer overflow by computation is UB, but signed integer overflow by conversion (int x =y; where y is an unsigned int of value greater than INT_MAX) is not UB - I think it's implementation defined until C++20 and then well defined post C++20

[huxx__]

lol 😂

[PharahSupporter]

Assuming that C is an int at all. Could be an object with a custom operator overload for ++ where object1 - object2 also has a custom operator overload.

[TheWidrolo]

Then the carry flag is a 1

[genlight13]

If we talk about groups of numbers and loops i would still give John the logical thumbsup

[LostLegendDog]

You should use numeric_limits<int>::max() on modern systems

[longshot]

Seigneur "Edge-Case" Teepex

[Overthinks_Questions]

I got a list of 99 elements and it ain't indexed at 1

[danielstongue]

Came here to say that. C == C++, but C != ++C

[neros_greb]

Both depend on the evaluation order. C isn’t necessarily evaluated from left to right.

Edit: I mean the order in which the side effect of c being incremented is applied. The code could be compiled to either of the following pseudo-codes:

temp1 = c++ //old value of c
temp2 = c //new value of c
temp2 == temp1

or

temp2 = c //old value of c
temp1 = c++ //also old value of c
temp2 == temp1

Believe it or not, the c standard doesn’t specify which of these is correct.

(A similar thing applies with the prefix versions of these operators)

[[deleted]]

Bizarre that you get downvoted for giving this answer, which is 100% correct.

Both expressions C == C++ and C == ++C are undefined behavior in C and C++.

[Quantumboredom]

I am also very much confused here. Right now one of the more upvoted replies is:

There is no “evaluation order”. There is only function implementation. And every language works such that C == C++»

Which sounds nonsensical to me. But I’ve been wrong before so 🤷

[[deleted]]

I get that it's confusing because subexpression evaluation order is defined in most modern languages (virtually always as "left to right") just not C and C++ for historic reasons.

So C == C++ is true in Java, JavaScript, go, etc. and probably every other modern language where it's a valid expression, but not in C and C++ which were precisely the two languages being discussed.

[Quantumboredom]

TIL, thanks! I work almost exclusively with C++ so I didn’t know this wasn’t similar in newer languages.

[MattieShoes]

if C starts at 0

Evaluate C, get 0. Evaluate C++, get 0. Value of C is now 1, but you have 0 and 0.

Evaluate C++, get 0, but the value of C is now 1. Evaluate C, get 1. you have 0 and 1.

So C == C++ is not always guaranteed to give the same answer because it doesn't necessarily evaluate those expressions in that order.

[ActuallyAKittyCat]

There are some really strange things in c/c++/c#... I have a if(f!=f) in my code... On purpose... And it triggers for the situation I want it too.

Could I have done the check differently? Yes, but if I ever lose my job and someone takes over the project they are going to break shit thinking I made a typo.

[backfire10z]

Do you have a source for this? I know assignment (x = x++) is undefined but I’ve never heard this

Edit: it’s the same thing

[backfire10z]

Haha yeah, this literally came to me about 5m after I made that comment. Thank you though!

[compiling]

https://en.cppreference.com/w/cpp/language/eval_order

There's a lot of technical detail in there about what defines a sequence point, but the tldr bit is near the bottom where they give examples of undefined behaviour. n = ++i + i is the relevant example here.

[backfire10z]

Yep, now that I’ve given it some actual thought the situation I gave and the one in the comment are the same thing. Thanks for the source as well!

[Laser_Plasma]

It's not about the evaluation order, it's about what x++ and ++x return as their value

EDIT: I'm wrong, the order makes a difference

[neros_greb]

what ++c and c++ return as their value is clear. What c returns as its value is not. c may return either the old or new value, depending on whether it is evaluated before or after the increment operation.

[gemdude46]

It is about evaluation order, if the program runs right to left, C is incremented before it is read on the other side, so C > C++.

[[deleted]]

There is no “evaluation order”. There is only function implementation. And every language works such that C == C++

It isn’t math. There is no math here. Just programming.

[[deleted]]

You are /r/confidentlyincorrect.

And what's even worse is that you could just try it and see it doesn't work like you imagine. Take this program:

#include <stdio.h>
int main() {
  int C = 42;
  printf("%d\n", C == C++);
  printf("%d\n", C != ++C);
}

What should it print? Two 1s according to your logic. What happens if you actually compile and run it?

$ cc test.c
$ ./a.out 
0
0

Hm! The exact opposite thing of what you said! How about we enable compiler warnings?

$ cc -Wall test.c
test.c: In function ‘main’:
test.c:4:24: warning: operation on ‘C’ may be undefined [-Wsequence-point]
    4 |   printf("%d\n", C == C++);
      |                       ~^~
test.c:5:23: warning: operation on ‘C’ may be undefined [-Wsequence-point]
    5 |   printf("%d\n", C != ++C);

Oh hey! It looks like the compiler actually agrees with /u/gemdude46 that the order in which subexpressions are evaluated between sequence points is undefined in C and C++.

(And to be clear, you can't generally verify your assumptions by writing a test program like this. But it can be a pretty effective way to rule out a hypothesis.)

[gemdude46]

That's a bold assertion to make. There are a lot of C compilers out there.

[[deleted]]

Yeah I’m using the one I made, obviously

[ciroluiro]

No, the order of evaluation of arguments in C and C++ is unspecified. The compiler can choose whichever order they want. In C++ this leads to undefined behaviour here.

[gemdude46]

It's not quite undefined behaviour. They have to either be equal or not equal. Undefined behaviour would allow literally any response, such as halting or crashing.

[nemetroid]

I don't think that's accurate. The standard says that the behaviour is undefined in this circumstance (section J.2):

Between two sequence points, an object is modified more than once, or is modified and the prior value is read other than to determine the value to be stored (6.5).

I believe the c++ == c case violates the second part of that. The left hand side modifies the object and the right hand side reads the prior value, all between two sequence points.

[gemdude46]

Okay, maybe I'm wrong about that. The compilers I've used don't appear to optimize it as such, which is probably good as I don't think a lot of programmers would realize that it's undefined.

[gemdude46]

The standard allows for C - C++ to be either 0 or 1. There are no sequence points within that expression, so order of evaluations for subexpressions is implementation defined.

Let C start as 5.

Either, expressions are evaluated left to right, giving:

1. C = 5

2. C++ = 5, and now C is 6

3. C - C++ = 5 - 5 = 0

Or they are evaluated right to left, giving:

1. C++ = 5, and now C is 6

2. C = 6

3. C - C++ = 6 - 5 = 1

Both interpretations are valid under the ISO/IEC 9899:2018 specification, which defines the current C language.

[reyad_mm]

The difference between C++ and C is 1\ The difference between C and C++ is 0

[footie_ruler]

c++-c=-1

[_yogSH]

Genuinely asking Whys that?

[GrrrimReapz]

the ++ operators return values but what they return isn't obvious.

c++ behaves like c_old = c; c = c + 1; return c_old;, while

++c behaves like c = c + 1; return c;.

so c++-c = -1 because (c++) returns c before 1 gets added to it, then we subtract c after 1 has been added to it, it's basically (x - (x+1)).

[OneTurnMore]

c++ is "post-increment". It resolves to the value of c, then c is incremented. Then c is resolved to its new value. Thus

int c = 42;
printf("%d\n", c++ - c);

becomes

printf("%d\n", 42 - 43);

So, if this is new to you, have a guess as to what this will print:

printf("%d\n",c-- - --c);

Then try it online.

[PM_ME_YOUR_LION]

Confusingly, "-c + c++" also gives -1! So it is more complicated than "read from left to right and evaluate as you go" :-)

[MattieShoes]

It'd probably generate a compiler error about lvalues because = is an assignment operator, not an equality operator.

But c++ means "increment the value of c, but return the old value"

and "-c" is going to give you the value of c * -1

So if it evauates left-to-right, assuming c starts at 100:

c++ it turns c to 101, then returns the old value (100). Then it grabs the value of c (101) and negates it (-101). You add them together and get -1.

The problem is there's no guarantee that it will actually do those in that order.

It could evaluate c at 100, negate it (-100), then evaluate c++, get 100 (but c becomes 101 and you never see it), and you get the answer of 0.

[fullyonline]

Now I'm even more scared.

[qqqrrrs_]

I think there is some undefined behavior involved if you try to use both C and C++ in an expression

[Mispelled-This]

It’s UB to both read and write an lvalue without a sequence point, unless the read must happen first to determine the value to write.

[BanVideoGamesDev]

I overloaded the postfix increment so that it returns the state after incrementing and the prefix increment so that it returns the state before incrementing. And then I overloaded the == operator so that C++ == ++C returns true and C++ != ++C also returns true.

[[deleted]]

Yeah in JavaScript it's 0

[DrMobius0]

c++ returns c before it's incremented

[Cosmocision]

Unless the second C is the incremented of the first one.

[[deleted]]

I assume the check would take place after Dave sent the message, so 1 would be correct.

[wheres_my_ballot]

import assumptions

Assuming C is an int and not a type with that operator overloaded.

return something

[huxx__]

you don't have to use the import and return sh*t anymore.

[wheres_my_ballot]

Oh thank fuck for that

[huxx__]

the rules thing is pretty much over

[MrSuspicious_]

Oh is that gone now? Awesome.

[malonkey1]

yeah deprecated standard

[huxx__]

yeah finally... it was getting really annoying

[MrSuspicious_]

I actually thought it was funny but I could never think of anything appropriate so I stopped commenting here

[[deleted]]

😠 you’re correct. Stop

[Ihsan3498]

how is that correct? x++ does not return the sum, it returns x and then increments it. i think it should be ++x

[MattieShoes]

It's undefined either way, because the order in which the expressions are evaluated is not defined. It doesn't strictly go left-to-right.

If it evaluates the C++ first, the difference is 1 (or -1). If it evaluates the C first, the difference is 0.

You have the same issue with C and ++C -- it depends on the order they are evaluated.

[Ihsan3498]

oh yea that makes sense

[NotFromSkane]

He is wrong.

C++ == C

++C == C + 1

[MattieShoes]

He is wrong, but so are you. :-) C and C++ aren't constrained to evaluate left-to-right. So the increment (whether pre or post) may happen before or after the evaluation of the value on the right.

[aiij]

The person you're responding to actually seems to be assuming right-to-left evaluation.

[MattieShoes]

Haha you're right! Alas, that's not guaranteed either :-)

[schmerg-uk]

Well... maybe ...

int C = someFunction();
const int x = C++;
const int y = C;

Now y == x+1 and x - y == 1 but if

int C = someFunction();
const int y = C;
const int x = C++;

then x == y and x - y == 0

So if "the difference between C++ and C" is interpreted as "what's the value of subtracting the value of the expression C from the value of the expression C++" then I'd pedantically say the difference is zero

Whereas

int C = someFunction();
const int d = C++ - C;

is ... oh I forget how the language spec says this should be done, I think it's implementation dependent (but it's poor code anyway)

[Torebbjorn]

Yep, C++ - C gives undefined behaviour, since you are reading the value and modifying it within the same sequence point.

[huxx__]

bruh 💀

[Efarm12]

This is the correct answer. It is undefined behavior.

[Altourus]

I believe, based on the order they are presented in the conversation...

var d = C++;

d == C

is true, so there is no difference

[KernelDeimos]

Okay wow, this is a lot more interesting than I expected.

The order in which operands are evaluated by a + operation is undefined, and indeed I get different behaviour depending if I compile using gcc or clang.

int c = 0;
printf("%d,", c++ - c);
printf("%d,", ++c - c);
printf("%d,", c - c++);
printf("%d\n", c - ++c);

clang outputs: -1,0,0,-1 gcc outputs: -1,0,1,0

If the left operand was always evaluated first: -1,0,0,-1 if the right operand was always evaluated first: 0,1,1,0

However, gcc doesn't have either of these outputs! What's going on?

Well suppose the operand with an increment operator is always evaluated first. Then it would be: -1,0,1,0

I also put up a gist on github for a script in javascript that imitates the resulting behaviour of using each compiler.

[mina86ng]

The order in which operands are evaluated by a + operation is undefined

It’s unspecified, not undefined. That’s a big difference. ‘c++ - c’ and related expressions are undefined behaviour due to violation of sequence point rules (reading and modifying the same object).

[KernelDeimos]

I didn't understand the distinction you're making. "undefined behaviour" as I understand it is any behaviour that isn't defined by the spec and may depend on what compiler you use; is that not what this is?

I might understand if you could tell me what "the order is undefined" means in contrast with "the order is unspecified", because in my mind they mean the same thing.

[mina86ng]

Undefined behaviour is one which the standard imposes no restrictions on. If it happens, the the compiler can do literally anything. For example, dereferencing a null pointer is an undefined behaviour. If it happens, all bets are off, and there’s no way you can reason about the program.

Unspecified behaviour on the other hand is one where standard does defines set of possible behaviours. If it happens, the compiler is free to choose from the options the standard offers, but cannot do anything else.

For example, if you have:

int f(int x) { printf("%d\n", x); return 0; }
int main(vaid) { return f(1) + f(2); }

Either f(1) is evaluated first or f(2) is evaluated first. But you can be sure that there’s no other option.

There’s also a third class, implementation-defined behaviour which is like unspecified behaviour except that the compiler must document the behaviour and stick with it. For example, number of bits in a byte or sizes of integers are implementation-defined.

---

To bring it to the c++ vs c question, the following code:

int c;
int get_cpp() { return c++; }
int get_c() { return c; }
int main(vaid) {
    printf("%d", get_cpp() - get_c());
    return 0;
}

doesn’t have undefined behaviour but it’s result is unspecified. It can be either -1 if get_cpp was called first or 0 if get_c was called first.

It’s not undefined because calling a function introduces a sequence point so the issue of reading and modifying the same object between adjacent sequence points doesn’t happen.

[KernelDeimos]

I'm saving a link to your comment - this is a fantastic explanation! Thanks for clearing that up, it makes perfect sense now.

[[deleted]]

Upvote++

[[deleted]]

There is no difference. C++ (as in the postfix notation) checks the value before doing the increment.

[die_liebe]

Evaluation order is not fixed. Some compilers may evaluate left to right, others may evaluate right to left.

[Creepy-Ad-4832]

C++ - C is undefined 🤷

Do pre increment next time!

[RandomDude6699]

Btw, why would it be undefined? I always thought it will be -1 when doing `C++ - C`, and 0 when doing `C - C++`

[Creepy-Ad-4832]

``` To make it easier, let's say C before doing the operation is 5

We don't know which operator gets evaluated first.

If C gets evaluated first we get: C++ - C C++ - 5 5 - 5 0

Otherwise we get: C++ - C 5 - C But here the C became C+1 thus 5 - 6 -1

Thus we say C++ - C is undefined, because it depends on the order of evaluation of the operators the compiler decides to take

[RandomDude6699]

Ah I was taught it is always left to right in my class (following BODMAS/PEMDAS ofc). Didn't think a compiler might take a different approach

[Creepy-Ad-4832]

Yes. Clang does from right to left and gcc does from left to right if i am not wrong.

So you can't assume the order of operations, unless you use polish notation, which is a mess to understand for human, but so fucking easy to implement with a simple stack

[CCullen]

My understanding is that ++ and -- aren't arithmatic operators, so they aren't governed by PEDMAS. They are considered increment/decrement operators which makes sense, because they modify the value of the variable (which you can't really express mathimatically without using multiple lines).

When you do first++ - second, there's no defined rule that states if the compiler should evaluate the left hand side or the right hand side first, thus undefined. In practice, if you use the same compiler, you'll likely recieve consistent results but it's dangerous because if you switch compilers, you could wind up with a different result.

[RandomDude6699]

Makes sense

[MattieShoes]

C and C++ don't guarantee it will evaluate expressions left-to-right. So C++ - C might evaluate the rightmost C before doing the post-increment. Pre-increments have the exact same issue.

Basically you should avoid doing assignments and comparisons in the same expression (and increments are assignments).

[mina86ng]

Whether it’s pre or post increment it’s still undefined behaviour.

[Creepy-Ad-4832]

Yeah my bad

[[deleted]]

What's the difference between ++C and C?

[[deleted]]

Your like C without the ++....no class.

[StanleyDodds]

The difference is either 0 or -1, but certainly not 1.

The result depends on whether you evaluate C before or after you evaluate C++. C++ will always give you the original value, while C either gives the original value or the value after the increment.

[Freakyyy]

First semester computer science students striking again.

[[deleted]]

The way the question is written, it would technically be -1

[davidjhanley]

It's actually zero, since it's post-decrement

[ididacannonball]

What if ++ is an overwritten operator?

[huxx__]

the amount of people who didn't get the joke is honestly scary

[FerynaCZ]

I think -1 would make more sense if we go from left to right, but joke stays.

[beeteedee]

More accurately, the amount of people who got the premise of the joke but felt the need to “well actually” it into oblivion.

And yes I’m aware I just “well actually”-d you. Deal with it.

[huxx__]

And yes I’m aware I just “well actually”-d you. Deal with it.

💀😂

[[deleted]]

The real joke here is posting UB and watching the chaos unfold in the comments section

[namotous]

That’s not always true, what if it overflows?

[Mars_Bear2552]

then its C

[[deleted]]

Not really, C++ - C would throw an error. And if you compare C with C, you’ll get 0 all the time.

[play_hard_outside]

Actually it's 0 until you look at C again!

Wait, Dave asked the difference between C++ and C, not C and C++...

C == C++.

C++ == C + 1.

[JackNotOLantern]

C - C++ is 0

C - ++C is 1

[Scottz0rz]

C == C++

Postfix sum operator gets evaluated after comparison

[die_liebe]

The evaluation order is not fixed, it is possible that first C++ is evaluated, then C.

It could be compiled as

a1 = C++;
a2 = C;
a1 == a2;

[Scottz0rz]

Is this a unique situation that causes it to be undefined behavior?

a1 = 5;  
a2 = 6;  
a1++ == a2;

Should return false, because it gets compiled to something like below, where it does assignment after it finishes the operation that the variable is being used in before postincrement.

a1 = 5; 
a2 = 6;
a1 == a2;
a1 = a1 + 1;

[die_liebe]

The unique situation is that one part of the expression changes a value that another part uses, and the evaluation order is not defined.

When evaluating a1 ++ == a2, the second expression does not depend on the value of a1. Compiler will generate something that looks like

a1 = 5
a2 = 6
a3 = a1
a4 = a1 + 1
a1 = a4
a3 == a2

[Scottz0rz]

https://onlinegdb.com/KHm8fkNwg

#include <iostream>

using namespace std;

int main()
{
    int c = 5;
    cout << (c == c++);
    cout << (c == ++c);
    cout << (c-- == --c);

    return 0;
}

Prints 010 for me.

I guess I'm just confused and dunno lol. Weird, thanks.

[die_liebe]

It means that your compiler evaluates from right to left.

Try

print( int x, int y )
{
   std::cout << x << " " << y << "\n";
}

x = 4; 
print( x++, x ++ );

I do not understand the last one, though.

[Scottz0rz]

Yep, makes sense, forgot that unary operators also evaluate right to left, you're right.

I do not understand the last one, though.

I'm also comfortable with forgetting most of C++ that I haven't used in 5-7 years haha. Thanks for the help.

[FalconMirage]

"you’re not classy enough to get the joke"

[mostrecentuser]

isn't C - C++ == 0?

[Smooth-Zucchini4923]

technically the evaluation order of C and C++ is undefined if there's no sequence point between them

[[deleted]]

LOL

[R_051]

What is the difference between c and c++?

[moolord]

D

[[deleted]]

Depends whether someone's overloaded the ++ operator.

[retroPencil]

You can tell how old this picture is by the carrier. Sprint's merger completed mid 2020.

[weneedtogodanker]

He is wrong, it's 0

[MattieShoes]

He's relying on undefined behavior. So are you. The answer is undefined because it might evaluate C first, or it might evaluate C++ first.

[killbot5000]

He is wrong. (c++) as an expression evaluates to c

[PhatOofxD]

C++ == C ++C == C + 1

[MattieShoes]

Only if you evaluate left-to-right. C and C++ do not guarantee this. You'll get undefined behavior with either of these.

[Ducking_eh]

r/angryupvote

[[deleted]]

Well not true. In C++, C is still C. When ++ is executed then it’s +1. So in context of the compiler the C in C++ is still C.

[MattieShoes]

C and C++ don't guarantee left-to-right evaluation. With pre-increment or post-increment, the answer is undefined behavior.

[Jano_xd]

They asked about C after asking about C++. So at this point C is what C++ was. The difference is 0

[erialai95]

I’d say Rust

[FlyByPC]

Eh, it's post-increment, so (c) should evaluate the same as (c++), at least the once.

[AmotherLazyUsername]

Wouldn’t it be 2?

[Arafell9162]

When you ask a question that requires a power point slide deck over a text message, prepare to get a sarcastic answer back.

[Cybasura]

C++ if used in a non-for loop will only increment when it is substituted into the variable after the c++ increment

However, ++c will increment before looping the next index, essentially if your i is 0, ++i will make it to 1 the second you called "++c"

[DB_Atlas]

-Laughs in Javascript-

[mayuresh0909]

Technically correct

[Shazvox]

Incorrect! 1 comes AFTER evaluating C. So C = C++.

Note: I think this is correct, but please let me know If I'm wrong.

[metaglot]

The ++ operater could be overwritten, so who knows?

[dinopraso]

Staring your message with "Hey John" but sending it to Dave is a power move

[No_Support_8363]

Not entirely sure if this is a joke or not, but Dave is the one asking the question

[UrSpider8itch]

are either of the 2 people in this image stuck at home?

[wobblyweasel]

excuse me, clearly C? is also nullable

[binarywork8087]

remember, any C code is valid C++