the great debate

!=

>>105794340 (OP)
> input is a negative number
> Rocket explodes for 'unknonw' reason.
> Millions of dollars lost because OP doesn't know the difference between > and !=
You will never be a rocket scientist.

>>105794340 (OP)
If count is unsigned you should use > for ancient architectures where gt doesn't modify the status register

>>105794376
> input is a negative number
This alone is reason to fire/not hire OP.

>>105794340 (OP)
Those are different things.

>>105794376
>var called $count
>its negative
you will never be an engineer

>>105794632
Variable names don't define the type of data they hold.

>>105794710
>Variable names don't define the type of data they hold.
astute observation my genius friend!

>>105794727
You're not smart. Never will be.

>>105794340 (OP)
If count is unsigned, then > is equivalent to !=. Additionally, if the upper limit is known, then use `count < max`.

>>105794814
Counter vars are too abusable and unsigned counters they'll fail the step isn't always 1. Implicit conversion will cause infinite loops too.

>they'll
will*

it costs costs nothing to eliminate a class of bugs and make it easier to reason about a program, but some retards will still be obstinate about it.

How is this a debate, > obviously.

>>105794340 (OP)
>>105794376
> is more correct because it implies the number should only ever be 0 or positive. if you use != then you are basically saying either "this number may be 0, positive or negative" or "i expect this number to sometimes be negative due to bad programming" neither of which are preferable if the number should only ever be positive

>>105795107
accidental meme arrow sorry guys

>>105794932
if we extend this logic then you should also introduce null checks for every single object in a method even if all the existing use cases do not allow a null reference to even exist. it eliminates null reference exceptions after all

>>105794814
No, it's not. Have you ever heard about integer overflow, chud? This whole thread is a fiasco and OP is chud.

>operators
lel, shit language.

(positive? $count)
(filter positive? '(1 0 0 2 3 0 4)) ; -> '(1 2 3 4)

>>105795120
null assertions are very common. they're also not completely free, so you are not comparing apples to apples.

>>105794807
projection & cope

>>105794902
>unsigned counters they'll fail the step isn't always 1
You mean "if the step isn't always 1"?
>Implicit conversion will cause infinite loops too.
This is more of a C problem than it is an unsigned problem. This can be mitigated by using unsigned integers for all variables and values which your counter will be compared against. You'll find that many such variables and values will also be non-negative by nature.

>>105795121
Do you even know how unsigned types work in C and its descendants? `count < max` works precisely because overflowing into the negative range yields a very large number that violates the condition.

>>105794457
>>105794632
This line of thinking is exactly why we have shitty software in production: Due to people that feel that every block of code they write is a means to satisfy their malignant need to constantly prove their intellect.
It also shows how you've never worked in a real enterprise ever. If you did, you'd know that speed of execution and high level / customer facing logic trumps whatever code crafting you want to do. You're there to make the employer money, not be an artisan.
This isn't even a debate.

>>105795475
>This can be mitigated by using unsigned integers for all variables and values which your counter will be compared against
No if you're using a countdown because the unsigned set isn't closed under subtraction, "(unsigned) small - (unsigned) large" will overflow. And unlike div between integers with a well behavior the result of that operation depends on the system (obviously people should never use == to compare the result of divisions)

>>105795753
>You're there to make the employer money, not be an artisan.
>This isn't even a debate.
Yes, because blatant retardation is profitable. Of course it isn't a debate. When you are licking windows, I don't need to argue about whether or not it is raining outside.

>>105795753
But nobody here asked about wageslaves

>>105794415
Please elaborate

>>105795164
>AI generating a cover for a book that already exists
Retard

>>105795164
is this forth?

>>105794376
this
anomalous fuckups happen with both hardware and software
trusting it'll always be a positive number could result in shit breaking irl and that could be life and death
assume shit erroneously fucks up, whether intentionally or not, and cover your ass with irrefutable checks
there's an old vi on youtube I think from LiveOverflow who demonstrated you can voltage-jump your way through if checks for something like a password check

how is this even a thread? two objectively different statements, but if this this were places in a while loop i would do (count > 0) just to knock on wood.

>>105794632
count is not an alias for "unsigned int", jeet, nor should you expect a symbol name to be foolproof logic.