Animated text

**Mario F.** · 07-08-2006

That was funny

But I was expecting it...

You don't have a problem with the operator. You simply have a problem of bad code.

**twomers** · 07-08-2006

... I've just realized how off topic this is.

**Mario F.** · 07-08-2006

Not really. Off topic would be discussing why for is better than against.

As a side note, I do hope you realize the examples you provided are in fact yet another reason to choose !=. The bug inside the loop will be clearly visible once one runs the program. There's no telling what will happen on the other instance where one chooses < or <=.

The program may crash (which is good) or keep running and yield undefined results (which is very bad).

**twomers** · 07-08-2006

I agree, but you didn't specify that in your request for flaws with the '!='

(nit picking and whatnot)

**bumfluff** · 07-08-2006

The only thing that I was thinking with my statement is that ifyour computer has some horrible glitch and then jumps over your limiting number in your for loop and that would mean that it would still be != and so would go into an infinite loop.

**Mario F.** · 07-08-2006

If such a thing happened then you, I, and the 16 megaton warhead launching engineer over there running your application, would want the program to crash. An infinit loop will do just that.

**whiteflags** · 07-08-2006

If you want to get the safest loop in the world, use the for_each algorithm. I'm sure they do this almost constantly in the nuclear weapons launching program.

Otherwise, for programs that we write, it is generally immaterial how we control for: Mario has merely proved that operator != is moderately safer in that it might crash the program, I'm more inclined to believe that this is undefined and the loop could run forever. > and < impose a ceiling which will stop the loop for sure.

**Mario F.** · 07-08-2006

Mario has merely proved that operator != is moderately safer in that it might crash the program,

No. More in the sense that it doesn't hide a bug in your code. It helps expose it. The "ceiling" provided by < or > operators may lead to undefined behavior if there was a bug and no checking being done after the loop ends. It has more potential to create an hard to find bug.

**ZuK** · 07-08-2006

Originally Posted by Mario F.

If such a thing happened then you, I, and the 16 megaton warhead launching engineer over there running your application, would want the program to crash. An infinit loop will do just that.

Me, being an engeneer ( luckily not working with warheads ), would prefer to keep the application running. I really hate it when I loose control of a process just because some possibly unimportant application crashes or locks the OS and I have to wait for a reboot. But I guess that is just a matter of perspective.
Kurt

**Mario F.** · 07-08-2006

Really? You still wanted your application to keep running under undefined behavior?

Maybe perhaps if the loop ended with a 1 being sent to OrderLaunch(bool yesno)?

**whiteflags** · 07-08-2006

I think the argument is still semantic at best. It's... actually difficult for me to believe that you think != is going to help you find a seg-fault if you dereference memory that doesn't belong to your custom container class, or loop past the end of a c-string. Or why you think it's difficult to inspect your loop after it outputs the results X times more than it should.

Don't loop the launch instruction! Verify it via Alpha Niner OP 314159-A. Or use for_each. Geez. Nobody listens to me.

**ZuK** · 07-08-2006

I am saying that as long an application runs there is still a chance for some corrective action. If it's dead no chance.
Kurt

**Mario F.** · 07-08-2006

Citizen,

I'm not advocating anything. I merely suggested that != might be a better approach to for loops. And I' sure I made it perfectly clear it is mostly a matter of taste. My opinion and that of those who defend this point of view is no more valid than anyone else's. Maybe if you stop, and slowly read the thread again you will see.

So please, don't step ahead of me in the line of "nobody is listening".

**whiteflags** · 07-08-2006

I believe it you read my post wrong.
> More in the sense that [not equal to] doesn't hide a bug in your code.
My previous reply was based on this statement, which clerly is no more true than what would happen if you used > or <. I did not say you were advocating anything, but what you are using to defend your point of view, and recommend that we switch from something natural is not making your point any stronger.

> You still wanted your application to keep running under undefined behavior?
Stopping a loop after i is not less than < 80 is defined. != would still be true, what happens?

My opinion is thus, and I will not repeat it.
We use != when it is necessary. If the loop condition will become an issue, for_each is good most of the time. Otherwise, as I've said, it's immaterial how to control for.

**Mario F.** · 07-08-2006

My opinion is thus, and I will not repeat it.
We use != when it is necessary. If the loop condition will become an issue, for_each is good most of the time. Otherwise, as I've said, it's immaterial how to control for.

That was my bloody point from the beginning! Thanks for adding nothing to this thread.

> You still wanted your application to keep running under undefined behavior?
Stopping a loop after i is not less than < 80 is defined. != would still be true, what happens?

I am really not going to reply to this citizen. It's... no words