This question already has answers here:
Is "for(;;)" faster than "while (true)"? If not, why do people use it?
(21 answers)
for loop missing initialization
(6 answers)
Closed 9 years ago.
Recently while going through a c++ tutorial I encountered a for loop that looked like this:
for (;;){
//Do stuff
}
Is this an infinite loop? Why would I use this rather that while(1)?
Yes, it's infinite. Traditionally, compilers would generate a warning when you use while(1), but not when you use for(;;). I don't know if this is still the case.
It's an infinite loop. More precisely, if the condition in a for is empty, it is considered true. As for while ( true ) vs. for (;;): historically for (;;) was the idiomatic form (used by Kernighan and Ritchie), perhaps partially because early C didn't have booleans. Using while ( 1 ) wouldn't pass code review anywhere I've worked. With booleans, while ( true ) definitely seems more intuitive than for (;;), but while ( 1 ) is confusing. But in pre-boolean times, everyone had a #define for true or TRUE or some such, so it's a weak argument. In the end, if you're an old C programmer, like me, who originally learned from Kernighan and Ritchie, you just instinctively use for (;;). Otherwise... it probably depends on where and from whom you learned C++.
Of course, when at work, you follow the house conventions, what ever they are.
Is this an infinite loop?
Yes.
Why would I use this rather that while(1)?
Because of (bad, IMO) taste. By the way, I would go for while (true), if I really had to create an infinite loop.
Related
This question already has answers here:
What for (;;) and while(); mean in C [duplicate]
(4 answers)
Closed 6 years ago.
In a c/c++ file I discovered a strange for loop
for (;;) {...}
I don't know if this runs once, infinetly or works in some other way
Source: https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/PreLoader.c Line 87
The for(;;) loop will continue forever until some command inside the loop causes it to terminate.
Some examples of such commands would be "break", or "return"
In the Linux kernel, infinite loops are written like this, instead of the usual while(true) or while(1) in other projects. This is a matter of style.
That is an infinite loop. It's an ordinary for loop with no condition expression. It is equivalent to while(1). It is a bit odd to the eyes of nearly all C and C++ programmers, and should be avoided. I think people from a C/C++ background are more likely to prefer while(1) rather than for(;;).
K&R 2nd ed 3.5:
is an ``infinite'' loop, presumably to be broken by other means, such
as a break or return. Whether to use while or for is largely a matter
of personal preference.
It's an infinite loop, equivalent to while(true). When no termination condition is provided, the condition defaults to true.
This question already has answers here:
What is the difference between if(CONST==variable) or if(variable==CONST)?
(5 answers)
Closed 9 years ago.
I've come across some code that flips how a condition is checked and was wondering why this would be done aside from a weird personal quirk. I've never seen any text books use it nor have I seen any sample code done this way.
// why do it this way?
if (5 == myValue)
{
// do something
}
// instead of:
if (myValue == 5)
{
// do something
}
I've only seen this way for == operand but not for any other operands.
Some people like doing that because if you mess up and type a single-equals instead of a double-equals, "if (val = 5)" is only a compiler warning, while "if (5 = val)" is an error (you can't assign to a constant).
I think it's sort of ugly, personally, and that you should be checking your warnings just as much as your errors, but that is the reason for that convention (which is thankfully not universal, but is at least moderately widespread. It is also true that it might not universally have been treated as even a warning by much older compilers, and this convention has been around for a long time.)
Fun fact: I was just reading Code Complete (Second Edition), and Steve McConnell agrees with me, stating his personal preference is "to use number-line ordering and let the compiler warn me about unintended assignments". Steve McConnell by definition knows what he's talking about.
Some folks do it for readability when myValue is deemed less interesting than 5; it puts the constant value in a more prominent place. There is no practical reason for it - purely a judgment call on the part of the coder.
This question already has answers here:
What is the difference between these (bCondition == NULL) and (NULL==bCondition)? [duplicate]
(6 answers)
Closed 9 years ago.
I have received code from someone working earlier on it, and it contains a lot of lines like
while(false==find && false == err && k<kmax)
if(true==refract(ep1,ep2,n1,RI_blood, RI_collagen))
and my favorite line is
if(false == (ret_s<0))
The other code is done really well, documented just fine, but these lines with these odd conditions are throwing me off, and I wonder why they are done that way.
Especially that false==(ret_s<0) is completely confusing, and you kind of need to read that line like three times to understand what they want there.
Is this a common programming style, don't I understand the reasoning for that, or is that just bad style?
Edit: I don't feel this is similar to if(object==NULL) vs if(NULL==object), since this isn't about accidental assigning but about obfuscated if clauses...
Is this a common programming style?
No.
don't I understand the reasoning for that?
Some people like to explicitly compare booleans with true or false, even though the result is exactly the same boolean value. The logic is presumably that, by making the code harder to read and more surprising, people will think harder about it and make fewer assumptions about its behaviour. Or perhaps just that code should be hard to maintain, since it was hard to write.
Others like to write comparisons with constants backwards, which prevents mistakes like if (x = 5) when you meant if (x == 5). Any modern compiler will warn you about this mistake, so again its only real purpose is to make the code harder to read.
Combining these two behaviours gives the bizarre code you posted.
Or is that just bad style?
It's a style. I'm no judge of style, but if you like to keep maintainence programmers on their toes, it certainly does that. Personally, I like my code to be readable, but that's just me.
my favorite line is
I once encountered return a && !b implemented in about ten lines of code. The first line was switch(a).
Yoda Conditions
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it's like saying "if blue is the sky" or "if tall is the man".
Its a safe guard against assignment in C++.
In C++ it is perfectly legal to do this
if (foo = true) ....
In this case the single = is an assignment and would replace the value of foo.
This is not legal and will generate a compiler error
if (true = foo) ....
Constants and literals are often put on the left because it prevents accidental assignments. Consider typing:
if(foo == bar)
as:
if(foo = bar)
The second might appear to work... but silently clobber foo. If foo is a constant, this error is not longer possible.
It's a self-protection technique that prevents you from accidentally typing an assignment operator (=) instead of equality operator (==), which can introduce strange bugs. Putting the constant value on the left hand side will introduce a compiler error, while putting a variable on the LHS will just silently compile.
Perhaps the original programmer thought that explicit comparison to true or false was clearler than if(condition) or if(!condition) and coded things in that way. I haven't seen this particular style before however.
It's quite subjective but I find while(!find && !err && k<kmax) easier to read.
The code could have been written for a shop where there is a site standard that every conditional statement must include a comparison operator, in order to avoid accidentally leaving out part of the comparison. (Maybe that's a stretch, but you did say that the rest of the code was very good.) That, coupled with a standard or habit of putting the constant on the left to avoid accidentally using = instead of == would give pretty much the code you showed. It doesn't explain the use of 'false' instead of the more natural 'true', though. Maybe it's a (misguided on multiple levels) attempt to gain microefficiency by comparing to zero instead of 1 at the machine level.
for my is only bad style,
if(false == (ret_s<0))
is equals to in C#
if(!(ret_s<0))
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is “for(;;)” faster than “while (TRUE)”? If not, why do people use it?
Found code with this for-loop.
What exactly feature to use it insted of while(true) for example? Is it uses less memory ?
for(;;) is functionally equivalent to while(true) but avoids a "conditional expression is constant" warning with some compilers (including MSVC's cl)
This construct has been popularized by Kernighan and Ritchie in their C Programming Language book (section 3.5)
The for statement
for (expr1; expr2; expr3)
statement
If expr1 or expr3 is omitted, it is simply dropped from the expansion. If the test, expr2, is not present, it is taken as permanently true, so
for (;;) {
...
}
is an "infinite" loop, presumably to be broken by other means, such as a break or return.
There is absolutely no difference between for(;;) and while(true).
while(true)
{
}
Is always what I've used and what I've seen others use for a loop that has to be broken manually.
Some compilers are giving you wrnings that this while loom MAY be incorrect. But it is not.
The assembly code generated for both is exactly the same. No diferences.
First, The use of loop depends on the requirement & based on that only we can decide when to use which one. Just check what #Luchian has asked, then you will come to know it.
Secondly, that clearly depends on the particular implementation of the interpreter/compiler of the specific language.
That said, theoretically, any sane implementation is likely to be able to implement one in terms of the other if it was faster so the difference should be negligible at most.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Is “for(;;)” faster than “while (TRUE)”? If not, why do people use it?
I was wondering what is the difference between for(;;) and while(1) when both perform same function? Will there be any difference of speed of compilation
The difference with these is that many compilers will warn about while(true) ("constant expression used as loop expression"), while none I know of warn about for(;;).
They should generate the same code, though.
no functional difference at all, just a matter of taste.
With for, you can do this:
#define ever (; ;) // note the two happy faces? ;)
for ever { ... } // endless loop
Which is not possible with while.
Both will cause infinite loop unless
break is called explicitly.
Personally I prefer while(1), it's
more readable
No difference. I prefer the latter.
6 of one, 110 of the other.
The latter appears more concise.
No difference, unless you want to make use some kind counter later as below.
for (int i =0; i < 100; i++) {
// some code
}
Both are the same in C++. However, your post is tagged with c# and c++.
If you're using C#, you'll need to use while (true) {...}. Personally, I prefer the same in C++: numbers are used only when dealing with... well, numbers! When dealing with boolean values, true and false are used instead.
They both defines the exact same functional behavior and produce exactly the same IL code from C#.
I'm old-school, I still do the following:
#define TRUE 1
#define FALSE 0
while (TRUE) { /*--do something, mutley--* }