|
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.
|
|
|
|
|
|
oh that's what delegates are
|
|
|
|
|
Unfortunately there's no button for 'wonderful answer'
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]
|
|
|
|
|
|
A delegate is an objective way of representing a piece of executable code. In particular, delegates represent a pairing of a method and the instance that the method acts on, but can also represent static methods.
Going hand in hand with delegates are anonymous methods, which allow you to use the 'delegate' keyword to define the code that a delegate will execute, without having to actually define a method first (this is how I personally use delegates 99% of the time):
public delegate int SampleDelegate( int foo );
...
public void SomeMethod() {
SampleDelegate del = delegate( int foo ) {
return foo + 1;
}
MessageBox.Show( del.Invoke( 5 ).ToString() );
}
...will show "6" in a message box. That's basically all there is to delegates. They're not at all complicated when you have a proper understanding of what they do.
The above example is of a static delegate, which does not apply to an instance, but you can, for example, capture a delegate of an instance too:
MethodInvoker del2 = myObject.SomeVoidMethod;
At least I think that's how the syntax looks--like I said 99% of the time I just use anonymous methods. (MethodInvoker is a special delegate definition for void( void ) methods).
“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!
-”-”-
|
|
|
|
|
If it helps, its just the address of a function, but strongly typed.
Say you have a method in code such as: int Add(int x, int y) { some code }.
This just means "Push x and y on the stack, run "some code", and then pop the return value back off".
When you call the method directly the location of "some code" code is fixed by the compiler. Delegates are just a way of changing where "some code" points to at runtime. So a delegate is just a type that represents "Some method that has these parameters and returns this, and the code is here".
This allows things like a Button to have a click "event" (which is essentially a list of delegates). All the Button class has to know is that delegates in the list are to be called with (object Sender, ClickEventArgs args) and they don't return anything.
|
|
|
|
|
Delegates :
Deleagates is a referance type used to call same signature method.
signature means here return type and Parameters
1.single Cast Delegates
2.Multi Cast Delegates ( Can be used to call Same signature multiple methods)
Return type of Multicast delegates Mus be void bcoz it has invocaion list
+= oprator is used to define Multicast Delagates methods
To remove Methods from delegates -= is used
Thanks
Raja.S
|
|
|
|
|
When would I use a struct in C#?
Everything Makes Sense In Someones Mind
|
|
|
|
|
When you want to make a type with value type semantics.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
By using structs, you can create objects that behave like the built-in types and enjoy their benefits as well.
when you instantiate a struct, it gets created on the stack. This will yield performance gains.
Vikas Amin
My First Article on CP" Virtual Serial Port "[^]
modified on Thursday, July 24, 2008 5:33 PM
|
|
|
|
|
vikas amin wrote: objects that behave like the built-in
Such as?
vikas amin wrote: enjoy their benefits
Which benefits?
vikas amin wrote: it gets created on the stack. This will yield performance gains
So, if I create a struct that has, say, 100 ints. That will be more performant than a class with the same?
What if I need to pass that object around? Say I need to pass it into a method or two?
|
|
|
|
|
Well of course, a nice neat stack is way better than a big untidy heap any day.
|
|
|
|
|
PIEBALDconsult wrote: Well of course, a nice neat stack is way better than a big untidy heap any day.
Nice reply!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
