Re: Why INFINITE loop in a thread occupy so much CPU time??
Actually, VC++ 6.0 does exactly what you claim K&R C did.
In debug builds:
$L74430:
; 10 :
; 11 : while(1);
mov eax, 1
test eax, eax
je SHORT $L74431
jmp SHORT $L74430
$L74431:
With the attendant warning about the constant expression.
On Sun, 18 Nov 2007 00:34:10 -0500, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
A compiler that diagnoses a conditional expression as constant has no contact with
reality. This is a common programming technique. I would certainly turn this warning
off. I once worked with another compiler that diagnosed this, as well as complaining that
a {} construct that was an empty set of statements was a warning. These are inconsistent
with good programming practice.
Good programming practice would consist of using the compiler at
highest warning level available, taking advantage of the intrinsic
proof-reading the compiler provides, yes it may seem stupid, but
stupid mistakes are avoidable mistakes by applying consistent style. I
must admit that I don't do this in GCC, it's a little too noisy
sometimes. :)
The reason the K&R compiler issued a warning was that their compiler did not optimize
this, so it actually would test the constant 1 to see if it was true! So for(;;)
generated better code, because the compiler was so poor. A good optimizing compiler would
not do that. Therefore, there is no point to the warning. Warnings like this presume
that the programmer is stupid. It is not at all uncommon to write code of the form
I was not aware the K&R C compiler issued any warning along these
lines. It wasn't until much later that this kind of linting was done
in the compilers.
if(SomeValue || OtherValue)
where SomeValue might be defined as a compile-time constant in some builds.
If SomeValue is constant and OtherValue is not, the warning is not
emitted. The warning is not that a constant is in the expression but
the expression evaluates constant. If both are compile-time constants,
then we're talking about what some might consider tricky code and it
might be worthwhile to use the pragmas at that point in the code and
document the reasons.
It may or may not be a programmer error, the compiler doesn't know.
The while(true) doesn't express this, the for(;;) does. I think I
would rather adopt the style of using for(;;) vs. writing the pragmas
for every compiler I use or even writing it as while(forever) as Tom
Serface did, for the reason he cited that the expression can always be
modified in the loop. The intent is self-documenting as well and the
code is set up for an easy edit.
Note that the MS compiler creates exactly the same code for both constructs:
Only in release. In debug it evaluates the constant, as shown above.
$L9626:
; 11 : while(true)
; 12 : if(DoSomething(i++))
00003 56 push esi
00004 e8 00 00 00 00 call ?DoSomething@@YA_NH@Z ; DoSomething
00009 83 c4 04 add esp, 4
0000c 46 inc esi
0000d 84 c0 test al, al
0000f 74 f2 je SHORT $L9626
$L9630:
; 13 : break;
; 14 :
; 15 : for(;;)
; 16 : if(DoSomething(i++))
00011 56 push esi
00012 e8 00 00 00 00 call ?DoSomething@@YA_NH@Z ; DoSomething
00017 83 c4 04 add esp, 4
0001a 46 inc esi
0001b 84 c0 test al, al
0001d 74 f2 je SHORT $L9630
; 17 : break;
therefore, there is no reason to presume that while(true) is worthy of being diagnosed as
something of the slightest interest to the programmer. I EXPECT to have conditionals that
turn out to be compile-time constants.
joe
On Sat, 17 Nov 2007 05:21:17 GMT, Geoff <geoff@invalid.invalid> wrote:
On Fri, 16 Nov 2007 23:10:12 -0500, Joseph M. Newcomer <newcomer@flounder.com>
wrote:
I consider any compiler that diagnoses while(TRUE) to be worthy of a warning to be a
compiler that does not understand reality.
joe
Interesting...
int main(void)
{
while(true);
return 0;
}
"warning C4127: conditional expression is constant"
Affected: All versions of Microsoft VC++ since I can remember and proven on VC++
6.0 and 2005.
Constructs like this don't emit diagnostics at /W4:
bool forever = true;
int main(void)
{
while(forever);
return 0;
}
One can write 'bool' in C++ but not C. On some implementations bool equated to
int so it's a distinction without a difference... unless you are dealing with
legacy DLL's:
__________________
Microsoft Specific
In Visual C++4.2, the Standard C++ header files contained a typedef that equated
bool with int. In Visual C++ 5.0 and later, bool is implemented as a built-in
type with a size of 1 byte. That means that for Visual C++ 4.2, a call of
sizeof(bool) yields 4, while in Visual C++ 5.0 and later, the same call yields
1. This can cause memory corruption problems if you have defined structure
members of type bool in Visual C++ 4.2 and are mixing object files (OBJ) and/or
DLLs built with the 4.2 and 5.0 or later compilers.
END Microsoft Specific
_________________
Use of while(1) is ancient in C and K&R NEVER wrote while(1) and in fact wrote
for(;;) as an infinite loop (page 60 of 1st Ed.) and stated explicitly on page
60 that use of 'for' in loop control was preferable to 'while' in most cases.
Programmers who write while(1) demonstrate profound ignorance of the C language
and loop constructs.