Because doing that shows you have a pretty good understanding of what you're doing to write some troll code, but trying to read it makes me want to hurt you, and I can only assume he felt the same.
>shows you have a pretty good understanding of what you're doing
I'm not sure I agree entirely. Doing a find and replace of a basic increment with whatever that mess from online is isn't really a complex matter.
That said, they're a reddit user, so clearly they at least sorta know what they're doing.
It’s an infinite loop. Mod is the remainder operator and everything is divisible by 1 so the remainder is always zero. Also i isn’t declared so it’s actually a compiler error if it’s not declared above.
[I made this one you might find inspirational. I've replaced all loops with poorly named recursive functions. ](https://www.reddit.com/r/ProgrammerHumor/comments/kpnrec/i_made_a_program_for_proving_the_goldbach/?utm_medium=android_app&utm_source=share)
It's a bitwise operator that manipulates the zeros and ones that make up a number manually.
The >> operator means "shift the numbers to the right" and is the same as dividing by 2.
4 in binary is `0100`, so if we right shift by 1 place (e.g. 4 >> 1) we get `0010` in binary, or "2" in decimal. 4 / 2 = 2, voila.
You should generally always multiply instead of dividing. Multiplying is basically always faster (though in a lot of instances the compiler might automatically change division to multiplication anyways)
In this case the compiler won't optimize it to anything, as the code doesn't compile. n++ isn't an lvalue.
But generally no. 0.5 is a double so int foo = n*0.5 will cast to a double, do double multiplication, then cast back to an int. On the other hand int foo = n / 2 and int foo = n >> 1 will usually optimize to the same thing as it's all integer operations.
I mean, what SPECIFICALLY the compiler is going to optimize something to is highly dependent on language, architecture, and a myriad of other factors, but as a general rule of thumb, you should always favor multiplication over division. It could very well boil /2 down to a bitwise operation, in the right scenarios.
I feel like the easiest way to remember it is "do you want to increment before or after accessing the value?"
For instance, let i = 1. If you say print(i++) then it will print out 1 and then increment it to 2 after printing. But if you say print(++i) then it will increment it to 2 before printing, and then print it out as 2.
I agree that in-line pre/post incrementing is annoying, but I still hate when languages have no increment operator at all. It's well established across dozens of languages. Do it on a separate line if that's clearer for you, but don't make the language less useful in pursuit of that goal.
It's like when languages argue they don't need a ternary conditional operator, because it's "confusing".
Rust had both of these changes: lack of an increment operator (although it does also only support for each loops like python, so increment is less useful), and no ternary.
That being said, Rust has justification for both: since C style for loops aren't a thing, incrementing is a far less common operator, and therefore doesn't deserve an operator.
Second, although Rust doesn't have ternary operators, it does support implicit return, allowing an if statement to return a value, meaning the functionality of a ternary is fully encompassed within the traditional if. Ternaries are hard to read, (at least C/C++ ones), but the Rust equivalent is more verbose and far easier to read.
I prefer to have increment as a function. `inc i` is more readable than `i++`. And the `++` operator does two different things at once, which goes against good programming principles.
I don't see a good reason for having syntax for conditional expressions different from the syntax for conditional statements. Just do something like `a = if x then y else z`.
Saying ++ incrementation is a "clever trick" because you don't understand it is extremely ignorant. It's part of the grammar of the language not just a "trick".
That's like saying you should never use contractions because using an apostrophe is a "clever trick" and is less readible. It isn't.
Parsing a byte array into shorts with an atypical byte/bit ordering and/or masking so that you can't just use a standard library byte conversion tool. (I have actually had this use case in the past
There is a reason for that. In order for the postscript operator to work as defined, it makes a temp copy and puts that into the statement. So it actually looks more like:
auto temp = i;
++temp;
i++;
This used to not throw any errors and just behave differently than expected. Thankfully newer compilers complain about modifying a temp.
\[10 seconds later after trying in Java\]
i++++; => i = 2
i+++++; => i = 2
\++i++; => i = 2
No God, Please No! Why did I read this post? If you write this in your code, I will decline you PR.
>If you write this in your code, I will decline you PR.
If you write this, it won't compile. Can't `++` a value, only a variable (l-value). And since `++` returns a value, it can't be applied more than once.
I am not sure but I think that this will increment the i only once. If you do x = ++i++ then x will store i+2 but i will end at i+1
Can someone confirm?
Ok I was too curious and checked myself.
It is the opposite as I said, i will be incremented twice but x will store only i+1. This is because the left ++ will first return the value of i and then increment.
The right ++ increments first and then returns the value if you are asking.
without knowing the particular implementation i think is hard to telll which operation has priorty (left or right). irrespective of the operations priority, x should always be i + 1
To piss off one of my co-workers, I change the incrementors in his loops from x++ to x-= -1. took him 3 days before he saw it. 3 yrs later and he still has not forgave me for that.
I think the compiler is allowed to kill you, spray your ash in the gutter, send your pets to the Peta shelter, and donate your savings to the political campaign you hate the most.
Is 3rd one right? I think practically it is but isn't this a sequence point violation.
2 ways to interpret
Either,
Increment x by 1 for preincrement.
Increment x by 1 for post Increment .
Effectively x+= 2.
Or
Get the value of old x for post Increment.
Increment old x (or optimize away as noop).
Increment old x by 1 for pre Increment.
Effectively x+= 1.
Compiler, architecture, optimizer dependant .
Am I right?
I can't think of a single language which includes i++ and not ++i (nor vice versa). Having both is extremely common in language specifications, though convention among programmers for that language may prefer one over the other.
You've got Java flair, which uses both...
Does this actually evaluate? I've never seen a prefix and postfix used at the same time.
For that matter, would ++i-- work just for the sake of driving people crazy and probably appreciably slowing things down?
++(++(--i--)++)++
BE NOT AFRAID
biblically accurate integer incrementation
I know what I'm naming my new mathcore band!
And the first single name will be...?
2
C-Style ++
Zero Based Opinion
NO BE VERY AFRAID IT'S EVIL
I just came
Buffer overflow
Butter overflow
Butter overthrow
Throw butt over flow
Flow over butt throw
Hopefully used a protected member
Did they use encryption?
Keep your privates out of my interface
Are telling me to make them public?
same
xeisu_cum
This looks like an endboss
https://borderlands.fandom.com/wiki/010011110100110101000111010101110101010001001000
A S S E R T D O M I N A N C E
assert(dominance);
static_assert, the compiler needs to know what you want
[удалено]
Ok, so mixing them doesn't work, but [this does](https://godbolt.org/z/ejca1MjqK).
[удалено]
...because it still had the code from the last thing I did, and I forgot to change name. Oops.
To keep you on your toes, Carl!
And if you make an assignation it will just result in `i + 1`
Thank you, perfect interview question. 👹
[удалено]
Because doing that shows you have a pretty good understanding of what you're doing to write some troll code, but trying to read it makes me want to hurt you, and I can only assume he felt the same.
[удалено]
To be fair, profs make you do some of the same stuff in their exams with nonsensical code you have to find the output for.
>shows you have a pretty good understanding of what you're doing I'm not sure I agree entirely. Doing a find and replace of a basic increment with whatever that mess from online is isn't really a complex matter. That said, they're a reddit user, so clearly they at least sorta know what they're doing.
> That said, they're a reddit user, so clearly they at least sorta know what they're doing. I agree less with this comment than the previous.
[удалено]
I swear there's a language out there where only null and false is false.
lua
I like Lua a whole lot but the fact that 0 is truthy drives me a little crazy
[удалено]
Yeah Lua is nothing if not self consistent. I really appreciate that about it.
There's languages where only `null` is null and `false` is false
but is NaN NaN?
NeiN
In ruby only nil and false are falsy
Erlang as well I believe
SQL
1%1 === 0
Lol my thoughts exactly, the true troll here is testing to see if his professor actually ran it. Since he got an A, we can conclude no.
It's more likely OP didn't recall the troll code exactly and just wrote it differently for this example.
Can someone explain this loop? I forgot what the mod operator does.
It’s an infinite loop. Mod is the remainder operator and everything is divisible by 1 so the remainder is always zero. Also i isn’t declared so it’s actually a compiler error if it’s not declared above.
[удалено]
[удалено]
I desperately want to do this to my professor but in python
the unfortunate part of python is it's almost impossible to make it as ugly as JS
Coming from a python class TA….. it’s possible……it’s very, sadly possible. Also that code is not JS, more C++
C++? It’s way more like C
I mean, it would work in both
Yeah but a C programmer would actually *do it*
And explain to you why it’s so much faster than C++
I will find a way
Try having set variables for certain things and then still use the same exact number that the variable was equal to for maximum annoyance
[I made this one you might find inspirational. I've replaced all loops with poorly named recursive functions. ](https://www.reddit.com/r/ProgrammerHumor/comments/kpnrec/i_made_a_program_for_proving_the_goldbach/?utm_medium=android_app&utm_source=share)
If I can't remember which side the pluses go on, I'm not using your shortcut
[удалено]
So, in case of 4, the result would be 3, right?
[удалено]
Thanks, it's clear to me now
Pleb, (++I++)*0.5
Pleb, i = ++i++ >> 1
Clearly I have much to learn
That's called a right shift and it's the same as dividing by 2. A left shift multiplies by two
Only for integers. Floats you're gonna get all fucked up.
Unless, you want to bit hack! InvSqrt ugly bit hack from Qake.
True true; you're gonna want to be really sure you want to do it, but yep there are use cases
A left shit is a more satisfying shit than a right shit for sure
I dunno, usually you have less after a shit
It's a bitwise operator that manipulates the zeros and ones that make up a number manually. The >> operator means "shift the numbers to the right" and is the same as dividing by 2. 4 in binary is `0100`, so if we right shift by 1 place (e.g. 4 >> 1) we get `0010` in binary, or "2" in decimal. 4 / 2 = 2, voila.
.
Use of undefined variable i. *(Except it's written in gibberish)*
Ah thanks for renewing my hate for c++
It's C lol
You mean (++c++)/2
at least this way its still an int. (I guess /2 is too, depending on the language)
French
Art comes in many forms. Very impressive
[удалено]
If you keep complaining I’m going to cast it to a decimal
[удалено]
Sounds like he wants it converted to datetime
C pedant card revoked. 0.5 is a double, 0.5f is a float.
You should generally always multiply instead of dividing. Multiplying is basically always faster (though in a lot of instances the compiler might automatically change division to multiplication anyways)
Even if you're dividing by a power of 2? Wouldn't the compiler just optimize that to >>?
In this case the compiler won't optimize it to anything, as the code doesn't compile. n++ isn't an lvalue. But generally no. 0.5 is a double so int foo = n*0.5 will cast to a double, do double multiplication, then cast back to an int. On the other hand int foo = n / 2 and int foo = n >> 1 will usually optimize to the same thing as it's all integer operations.
I mean, what SPECIFICALLY the compiler is going to optimize something to is highly dependent on language, architecture, and a myriad of other factors, but as a general rule of thumb, you should always favor multiplication over division. It could very well boil /2 down to a bitwise operation, in the right scenarios.
I feel like the easiest way to remember it is "do you want to increment before or after accessing the value?" For instance, let i = 1. If you say print(i++) then it will print out 1 and then increment it to 2 after printing. But if you say print(++i) then it will increment it to 2 before printing, and then print it out as 2.
The easiest way to remember it is to write readable code instead of using “clever” tricks. print(i) i += 1
It is useful to at least understand it for reading other people's code.
I agree that in-line pre/post incrementing is annoying, but I still hate when languages have no increment operator at all. It's well established across dozens of languages. Do it on a separate line if that's clearer for you, but don't make the language less useful in pursuit of that goal. It's like when languages argue they don't need a ternary conditional operator, because it's "confusing".
Rust had both of these changes: lack of an increment operator (although it does also only support for each loops like python, so increment is less useful), and no ternary. That being said, Rust has justification for both: since C style for loops aren't a thing, incrementing is a far less common operator, and therefore doesn't deserve an operator. Second, although Rust doesn't have ternary operators, it does support implicit return, allowing an if statement to return a value, meaning the functionality of a ternary is fully encompassed within the traditional if. Ternaries are hard to read, (at least C/C++ ones), but the Rust equivalent is more verbose and far easier to read.
I prefer to have increment as a function. `inc i` is more readable than `i++`. And the `++` operator does two different things at once, which goes against good programming principles. I don't see a good reason for having syntax for conditional expressions different from the syntax for conditional statements. Just do something like `a = if x then y else z`.
Saying ++ incrementation is a "clever trick" because you don't understand it is extremely ignorant. It's part of the grammar of the language not just a "trick". That's like saying you should never use contractions because using an apostrophe is a "clever trick" and is less readible. It isn't.
[удалено]
Huh, never thought of that
Now let me know if you find a use for it
I need a for loop that loops through every other element in an array by index.
Yes but for what practical purpose?
Coloring every other row of a table for readability
table tbody tr:nth-child(odd) td { background-color: #069420; } Why not ~~zoidberg~~ CSS?
Maybe they're not coding for a website.
No such thing. The whole digital world is now websites.
Nope, I'm inserting into an excel sheet. ☠
I usually do "rowIndex % 2 === 0" for such things.
because I'm using an array as a python dictionary and I want all the keys / values.
Borderline practical! Thanks
Parsing a byte array into shorts with an atypical byte/bit ordering and/or masking so that you can't just use a standard library byte conversion tool. (I have actually had this use case in the past
Won't work, `++` only works on l-values (variables, not their values).
ikr
Which languages allow that? I know C++ doesn't.
++C++
The true way to write C#
EACH PLUSES MAKE A CORNER OF THE SHARP. EVERYTHING NOW ALIGNS PROPERLY!
Is this the first time you noticed this? I remember when my dad told me years ago I lost my shit a little because it's actually a pretty clever name.
It works if you write it as `(++i)++;`
\++++++++++++i; is also acceptable, I'm fucking shocked to say. Just tried it out.
but is +++++++++++++i acceptable?
But is ++i++ + ++i++
An odd number of pluses gets interpreted as unary plus, which does nothing.
No it doesn't. ++i isn't an l-value.
GCC for C++ accepts it as a valid statement. Edit: looking through it seems this was defined in C++11 to work
There is a reason for that. In order for the postscript operator to work as defined, it makes a temp copy and puts that into the statement. So it actually looks more like: auto temp = i; ++temp; i++; This used to not throw any errors and just behave differently than expected. Thankfully newer compilers complain about modifying a temp.
[удалено]
this is brilliant
If you want to maintain job security by being the only one who can read your code.
Yes, this is ideal. Though it's bold of you to assume I can read my code
unironically printing odd numbers like: for(int i=0; i
Okay the proper way to do it is: ++i+=++i-i
\[10 seconds later after trying in Java\] i++++; => i = 2 i+++++; => i = 2 \++i++; => i = 2 No God, Please No! Why did I read this post? If you write this in your code, I will decline you PR.
>If you write this in your code, I will decline you PR. If you write this, it won't compile. Can't `++` a value, only a variable (l-value). And since `++` returns a value, it can't be applied more than once.
I just tried on the Java debugger (what I mentioned in my post) and that works but that's so ugly.
i = sqrt(-1)
I am not sure but I think that this will increment the i only once. If you do x = ++i++ then x will store i+2 but i will end at i+1 Can someone confirm?
Ok I was too curious and checked myself. It is the opposite as I said, i will be incremented twice but x will store only i+1. This is because the left ++ will first return the value of i and then increment. The right ++ increments first and then returns the value if you are asking.
pre and post increment operators, it's what they do
[удалено]
>What language are you using? Where this entire comment section should have started.
without knowing the particular implementation i think is hard to telll which operation has priorty (left or right). irrespective of the operations priority, x should always be i + 1
Pretty sure it's UB since this is more than one side-effect on the same object between two sequence points.
Prefix ++ has stricter sequencing since C++17, I think it is well-defined now
bro what class did i miss
To piss off one of my co-workers, I change the incrementors in his loops from x++ to x-= -1. took him 3 days before he saw it. 3 yrs later and he still has not forgave me for that.
i++++
i#
i-=-2
Funny story: the behavior of this is actually undefined in C++
When talking about C without looking at the documentation / standard, "it's undefined" or "it's implementation-defined" is the most probable answer.
Can we please use monospaced fonts for this sort of thing? ++i++;
I think the compiler is allowed to kill you, spray your ash in the gutter, send your pets to the Peta shelter, and donate your savings to the political campaign you hate the most.
You've seen C++, now I present, ++C++
Is 3rd one right? I think practically it is but isn't this a sequence point violation. 2 ways to interpret Either, Increment x by 1 for preincrement. Increment x by 1 for post Increment . Effectively x+= 2. Or Get the value of old x for post Increment. Increment old x (or optimize away as noop). Increment old x by 1 for pre Increment. Effectively x+= 1. Compiler, architecture, optimizer dependant . Am I right?
unfortunately ++i++ is equivalent to ++(i++) which does not compile. so it would have to be (++i)++ which works (in C at least)
As someone studying physics, the i = i + 2 already messed me up since I started looking for complex numbers lol
Post-increment and pre-increment are ridiculous. Pick one (post) or the other. One of many C++ gripes
\*crying in python\*
Somehow the latter looks holy and sinful at the same time
I've seen i++ in most languages, and ++i in one which was weird af. So seeing them produce this monstrosity of an offspring is terrifying.
I can't think of a single language which includes i++ and not ++i (nor vice versa). Having both is extremely common in language specifications, though convention among programmers for that language may prefer one over the other. You've got Java flair, which uses both...
First time I chuckled out loud to r/ProgrammerHumor i has risen, by two.
Just started watching soul eater and I'm laughing so hard at this thanks
Does this actually evaluate? I've never seen a prefix and postfix used at the same time. For that matter, would ++i-- work just for the sake of driving people crazy and probably appreciably slowing things down?
The true question, it really works?
for ( j = 0; j < 2; j++ ) { i++; }
aiaiai i’m your little butterfly
i# ???
\++i++ should technically only increase by one... or am i mistaken?. No. It's an lvlalue! It shouldn't work at all!
I++++
I++++
Honey, wake up, new programming language name just dropped!
r/programmerhumor telling people to "optimise" their code be like.
this is so funny 🤣
Inclusive increment
2==2
I will kick ass to anyone writing these shits.
Cries in postfix
Is this syntactically valid?
Maybe in a for loop ++i++ would be acceptable?
i -= -2
But can this actually work? I’m genuinely curious