|
Because you have to wait forever to tell for certain if a loop is infinite: he hasn't got the time.
Steve
|
|
|
|
|
|
That gets a +5 from me :P
|
|
|
|
|
Stephen Hewitt wrote: Because you have to wait forever to tell for certain if a loop is infinite: he hasn't got the time.
Consider that an eternity for the computer is a short time for a human. 1 000 000 000 000 000 iterations would only take a week or so... 
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
MarkBrock wrote: Is it an infinite loop?
Yes.
It equals with :
while (true) { ... }
|
|
|
|
|
It is infinite loop. But I would not do that if I where you, I would probably use Threading.Sleep if the purpose is to wait for an event to happen. infinite loop keeps utilize a lot of cpu...
|
|
|
|
|
Infinite loops are legitimate for certain things, especially when implementing threads and stuff that need to continuously run and wait (i.e. actually block, thus not using the cpu) for things.
Personally I prefer while ( true ) because it's more obvious what it is.
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
for ( ;; ) is the recommended way to do an infinite loop.
Steve
|
|
|
|
|
Is there a reason that is so?
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
When you maximize warnings the "while(true)" is correctly flagged as using a constant in a conditional expression.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Well aside from this (which as I see it is just a problem with the warning that it doesn't make an exception for obviously intentional infinite loops), there's no functional difference so I can't see why one is "recommended" over the other.
Nevertheless, do what you will, I'm only saying I like it better because it's more readable.
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
From a code generation perspective there is no difference. But there are many constructs which have no functional difference, but which generate warnings because they are prone to error.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
why not while(1)? (or while(true))
Is there a difference?
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
Click here to view my blog
|
|
|
|
|
You'd like to think the compiler is smart enough to produce optimal code in any of these cases, but I haven't verified this in C#. Nevertheless, for ( ; ; ) is the preferred way to express an infinite loop.
Steve
|
|
|
|
|
MarkBrock wrote: why not while(1)?
Because 1 is not a Boolean expression.
|
|
|
|
|
Colin Angus Mackay wrote: Because 1 is not a Boolean expression.
Whoops your right, in this forum anyway.
while(true) {} for C# 
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
Click here to view my blog
|
|
|
|
|
This is something I personally don't agree with. I think the while(condition) is much clearer as to its intent. The compiler warnings of constant-in-conditional are warning of possibly unintended code, when it this case it is 100% intentional.
That said, its not very often you need to actually have an infinite loop. Usually threads with while(true) should be implemented with while(!done). (Often they are stopped with ThreadAbort in random places)
I also see a lot of while { if(!data) sleep(1); else process();} patterns instead of re-registering at the end of an async callback.
Some of the worst maintenance nightmares have been on supposedly "high avaliability" systems with a lot of that. Small sleep intervals often return immediately, and theres not much point trying to sleep for less than a scheduling quanta. Things that need to be done quickly (priority), but infrequently are often poorly implemented with the while-sleep(1) pattern, leading to a tight loop that sucks down CPU. People need to learn how to use Monitor.*
|
|
|
|
|
Mark Churchill wrote: People need to learn how to use Monitor.
Agreed. Once you get your head around it, Monitor is actually a pretty easy class to work with. The only thing I still have trouble with is the difference between Pulse() and PulseAll() :P
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
Cheers,
I'm not interested in using it, I just wanted to confirm it was in-fact infinite.
I would usually use a while(true) for an infinite loop.
Thanks for your help.
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
Click here to view my blog
|
|
|
|
|
glad to be of help
|
|
|
|
|
MarkBrock wrote: Is it an infinite loop?
Yes, it is.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
MarkBrock wrote: Is it an infinite loop?
Only if there is no code to exit the loop in //do stuff.
|
|
|
|
|
I don't understand delegates at all. I'v read many books and articles, and followed the examples, but I still don't get it.
Everything Makes Sense In Someones Mind
|
|
|
|
|
A delegate is basically a reference to a method.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
