for(;;) ? valid : bad programming
- Thread starter btph
- Start date
That's one way to do it. It does not really matter practically if you use that or while(1) but some compilers warn on the use of while(1).
while(condition) is definitely clearer from a style point of view though.
while(condition) is definitely clearer from a style point of view though.
Last edited:
LMFAO at thread title 
theres nothing wrong with it, though it is identical to while (true){}. Infinite loops are fine, but if you want to drop out of it neatly, you should at least give boolean flags for "successful" dropout of "failure" dropout... for example :
bool continue = true, success = false;
while (continue) {
// do whatever
}
// if you reached this line, continue was exited, and you can at least test success to see what conditions it exited under.
theres nothing wrong with it, though it is identical to while (true){}. Infinite loops are fine, but if you want to drop out of it neatly, you should at least give boolean flags for "successful" dropout of "failure" dropout... for example :
bool continue = true, success = false;
while (continue) {
// do whatever
}
// if you reached this line, continue was exited, and you can at least test success to see what conditions it exited under.
There is no bool in C fyi.
thanks for all the responses, very informative. it seems like its acceptable to most.
to my mind though,
for ( ; ; )
and
while ( 1 )
must be poor programming style at the very least.
conveying programmer intention is surely best served with....
while ( TRUE )
anyway, question answered.
cheers
bill
ps talking more generally about programming style, anyone have any good sites or books that discuss it? I run a software department that is just moving over to C and would love to produce a "rules" book, but dont really know where to start!
to my mind though,
for ( ; ; )
and
while ( 1 )
must be poor programming style at the very least.
conveying programmer intention is surely best served with....
while ( TRUE )
anyway, question answered.
cheers
bill
ps talking more generally about programming style, anyone have any good sites or books that discuss it? I run a software department that is just moving over to C and would love to produce a "rules" book, but dont really know where to start!
while (TRUE) is no better than either for (; ; ) or while (1), all three are equally understandable to any half way competent C programmer. However, in the majority of cases, the uses of infinite loops is not terribly good style and could be better achieved with a properly placed control variable.
Could I ask why it is that you are moving over to C, rather than going to C++?
Could I ask why it is that you are moving over to C, rather than going to C++?
Last edited:
As I say I'm a noob to C so bare with me. So is 1 (or non-zero presumably) actually defined as true? I thought I had read of some compilers reversing this, I may be wrong though.
The reason for not going to c++ is that its for embedded systems, its still quite difficult to get c++ compilers. There is almost never any problems getting a straight C compiler.
Bill
The reason for not going to c++ is that its for embedded systems, its still quite difficult to get c++ compilers. There is almost never any problems getting a straight C compiler.
Bill
1 is used as a failure return from a function wheras 0 is a success. We use [noparse] for(;
[/noparse] rather than while(1) where I work.In C zero is false, while non-zero is true. A boolean operator will always resolve to 1 for true. So while(1) will do the same as while(TRUE) and the same as while (3) or while (-724). In fact, most likely TRUE is being #defined as 1.
That's a good enough reason. Have you looked into Embedded C++ though? As I understand it's available for almost all such systems.
The usual in C (if you're using error return) is for 0 to be success, while any non-zero is a failure code, on the basis you only need one way of returning succes, while you may have multiple failure codes.
Mr Jack (and everyone else) thanks for the replies. most helpful.
I particularly like the info about zero and non-zero return/error codes, always easier learning things when you know a bit more detail about the whys and wherefores. All good stuff.
As for embedded c++, it is becoming more common, but still nowhere near ubiquitous. We use quite a few different platforms, so its useful to have code in as portable format as possible. C fits that bill nicely. Having said all that, we used to use assembler!!
I particularly like the info about zero and non-zero return/error codes, always easier learning things when you know a bit more detail about the whys and wherefores. All good stuff.
As for embedded c++, it is becoming more common, but still nowhere near ubiquitous. We use quite a few different platforms, so its useful to have code in as portable format as possible. C fits that bill nicely. Having said all that, we used to use assembler!!