while (true) and for (; ; ) [modified]
-
I don't find many situations where I must use either. Something like while(!done) gives you a control over whether and when to exit, normal or abnormal.
Best, Jun
Not always. In
C
applications, for instance, you may know in the middle of the loop that you've to exit and while you may skip the following statements with anif
and then use the condition, I prefer an immediatebreak
.If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I have only used them, or their equivalent in other languages, for testing something. Never in production.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
-
What are your views on these? How often do you use or see them and in what cases? Just curious, it's a little debate with my project's Architect. To clarify, I don't mean the preference between the 2, but the use of such loops in production.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
modified on Thursday, March 10, 2011 12:10 PM
-
What are your views on these? How often do you use or see them and in what cases? Just curious, it's a little debate with my project's Architect. To clarify, I don't mean the preference between the 2, but the use of such loops in production.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
modified on Thursday, March 10, 2011 12:10 PM
-
I just used while(condition); in a unit test to test an async method for retrieving a business object. I can't imagine a use for them in production code though.
There is no failure only feedback
That's not even in the same category.
Curvature of the Mind now with 3D
-
I just used while(condition); in a unit test to test an async method for retrieving a business object. I can't imagine a use for them in production code though.
There is no failure only feedback
any way, if you are targeting 4.0, check this: SpinUntil[^]
Curvature of the Mind now with 3D
-
What are your views on these? How often do you use or see them and in what cases? Just curious, it's a little debate with my project's Architect. To clarify, I don't mean the preference between the 2, but the use of such loops in production.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
modified on Thursday, March 10, 2011 12:10 PM
-
I think I've used while true a few times, mostly in either complicated parser code, or early on when I was learning threading. It can make sense when side effects and the loop exit criteria are so intertwined that you can't separate them easily to reduce the exit to a single boolean. However, that's a huge flag to refactor/write your code so things aren't so intertwined. If you don't have the time/flexibility to do that, then I'd choose while (true) over creating a convoluted mess of a loop body just to have a boolean value to exit on.
Curvature of the Mind now with 3D
By the time your code gets too noxious to write a good exit condition, it's also too noxious to easily debug without dismantling the mess first. Unless you can write bugfree codethulus on the first attempt, there's no excuse for letting it get that bad in the first place.
3x12=36 2x12=24 1x12=12 0x12=18
-
any way, if you are targeting 4.0, check this: SpinUntil[^]
Curvature of the Mind now with 3D
-
By the time your code gets too noxious to write a good exit condition, it's also too noxious to easily debug without dismantling the mess first. Unless you can write bugfree codethulus on the first attempt, there's no excuse for letting it get that bad in the first place.
3x12=36 2x12=24 1x12=12 0x12=18
Yeah, I guess I'm too used to batting cleanup and having to pick my battles.
Curvature of the Mind now with 3D
-
I don't understand your other reply but this one is gold! Thanks for that I'm going to use it immediately.
There is no failure only feedback
All I'm saying is that while(true) { do something repeatedly } sometimes has a place in real code. The other while(checkSharedVariable) {}; is just a good way to kick up your CPU power consumption.
Curvature of the Mind now with 3D
-
All I'm saying is that while(true) { do something repeatedly } sometimes has a place in real code. The other while(checkSharedVariable) {}; is just a good way to kick up your CPU power consumption.
Curvature of the Mind now with 3D
-
:-D
Curvature of the Mind now with 3D
-
Ah, I'm going to modify my original post. I wasn't referring to the preference between the 2, but the use of infinite loops, especially if there is no breaks to exit the loop. I guess we have a crash-only design for some applications.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
Those constructs are usually seen in non-ineractive microprocessor embedded systems - I use them all of the time for the main "idle loop". I rely on a watchdog timer to restart the application if something hangs.
Steve _________________ I C(++) therefore I am
-
Yeah, I guess I'm too used to batting cleanup and having to pick my battles.
Curvature of the Mind now with 3D
-
What are your views on these? How often do you use or see them and in what cases? Just curious, it's a little debate with my project's Architect. To clarify, I don't mean the preference between the 2, but the use of such loops in production.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
modified on Thursday, March 10, 2011 12:10 PM
The only place I can remember using endless loops is in thread procedures. There often is no break, but of course I catch the ThreadAbortException to exit the loop. For example, a 3D rendering thread would be started at the beginning of the application and render as many frames as fast as it can until the thread is ended. Ending threads with an exception always appeared a little strange to me, because this definitely is changing the program flow with exceptions, but at least it has worked as expected up to now.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011
-
Okay, I can't think of why anyone'd have a while-true (or otherwise infinite) loop that does not have any normal exit conditions. Although you could break out via an exception it just does not seem very clean to me.
Regards, Nish
New article available: Resetting a View Model in WPF MVVM applications without code-behind in the view My technology blog: voidnish.wordpress.com
I wrote it below: A thread procedure without a clear number of iterations. Threads are terminated with an exception, but I also think that's not clean. But Bill wants it that way.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011
-
RugbyLeague wrote:
IDisposable to classes in C#
That's silly. It serves no purpose, except obfuscation and misrepresentation, if you don't implement the IDisposable!
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams "Let me get this straight. You know her. She knows you. But she wants to eat him. And everybody's okay with this?" - Timon
I implement it - it just doesn't do anything. I like how a "using" easily and obviously defines a scope for a class.
using(var foo = new foo()) { foo.DoStuff(); }
feels better than:var foo = new foo(); foo.DoStuff();
because in the latter foo is still in scope after use - the former more explicitly defines the useful lifetime of foo - I know there are other probably more correct ways of doing this. I just like the "using" notation. I don't always use it of course. -
They are both handy from time to time (expression parsing and times when you don't know how many iterations will be needed). I personally prefer while(TRUE) so as not confuse any VB programmer that comes across my code.
bob16972 wrote:
I personally prefer while(TRUE) so as not confuse any VB programmer that comes across my code.
:confused: Isn't that a reason to use
for(;;)
? -
What are your views on these? How often do you use or see them and in what cases? Just curious, it's a little debate with my project's Architect. To clarify, I don't mean the preference between the 2, but the use of such loops in production.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
modified on Thursday, March 10, 2011 12:10 PM
I'd prefer someone do this:
while(true)
{
if(matched condition A)
{
do something A
break;
}if(matched condition B)
{
do something B
break;
}}
to this:
bool exit = false;
while(!exit)
{
if(matched condition A)
{
do something A
exit = true;
continue;
}if(matched condition B)
{
do something B
exit = true;
continue;
}
}It's messy, longer and more prone to bugs when being supported/extended, and all just to avoid the "infinite loop", even though really it's just as "infinite".