infinite loops

[Vector]

Is any infinite loop better than other? Is there any difference between
there efficiency?

[Phlip]

Vector wrote:

Is any infinite loop better than other? Is there any difference between
there efficiency?

To what use will you put the answer? A compiler will treat for(;;) and
while(true) the same. The second takes longer to type. Always optimize
programming time.

The second might trigger a "conditional expression is constant" warning of
some type.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Ian Collins]

Vector wrote:

Is any infinite loop better than other? Is there any difference between
there efficiency?

Define better.

Which conveys the intent better? I'd say while( true ){}

Efficiency shouldn't be an issue.

--
Ian Collins.

[red floyd]

Vector wrote:

Is any infinite loop better than other? Is there any difference between
there efficiency?

I'm going to assume this is a joke.

Have you determined that the infinite loop is your bottleneck? How
long does your infinite loop take to complete? Have you benchmarked to
see if your infinite loop runs in aleph-null time versus aleph-one time?

[Tomás]

Vector posted:

Is any infinite loop better than other? Is there any difference between
there efficiency?

In practise, they are the same. Compilers will produce the exact same
machine code for these:

for (;;) { int k = 7; }

while (true) { int k = 7; }

do { int k = 7; } while (true);
In theory, the first one is fastest because there's no condition being
tested for each iteration of the loop.

I myself use for(;;).
-Tomás

[Gaijinco]

This is slightly off-topic but I found it intresting: What does this
code prints?

#include <iostream>

int main()
{
int i=1;

while(i>0)
++i;

std::cout << i;

return 0;
}

[amt.dwivedi]

Gaijinco wrote:

This is slightly off-topic but I found it intresting: What does this
code prints?

#include <iostream>

int main()
{
int i=1;

while(i>0)
++i;

std::cout << i;

return 0;
}

well answer is very obvious
it will print negative number that is shortest one.
reason : consider the same code with little modification for ur
understanding
int main()
{
char i=1;

while(i>0)
++i;

std::cout << int(i);
std::cin.get();

return 0;
}
print -128
i increments from 1 to 127 than incrementing further will make it 127
to -128
this is wat the range of char -128 to 127.

[Tomás]

Gaijinco posted:

This is slightly off-topic but I found it intresting: What does this
code prints?

#include <iostream>

int main()
{
int i=1;

while(i>0)
++i;

std::cout << i;

return 0;
}

As far as I know it's undefined behaviour for a signed integral type to go
past its limit.

In practise though, on a 32-Bit system, I'd hazard a guess that it'd be one
of the following:

0
-1
-4294967296
-Tomás

[Rolf Magnus]

am*********@gmail.com wrote:

Gaijinco wrote:

This is slightly off-topic but I found it intresting: What does this
code prints?

#include <iostream>

int main()
{
int i=1;

while(i>0)
++i;

std::cout << i;

return 0;
}

well answer is very obvious
it will print negative number that is shortest one.
reason : consider the same code with little modification for ur
understanding
int main()
{
char i=1;

while(i>0)
++i;

std::cout << int(i);
std::cin.get();

return 0;
}
print -128
i increments from 1 to 127 than incrementing further will make it 127
to -128

It might do this, or it might do anything else. The overflow behavior of
signed integers is undefined.

[Jack Klein]

On 25 Mar 2006 20:42:34 -0800, "Vector" <su***********@gmail.com>
wrote in comp.lang.c++:

Is any infinite loop better than other? Is there any difference between
there efficiency?

How could one infinite loop be better than another? Could one be
infinitely more infinite than the other? If one ends before the other
does, the comparison was invalid because the one that ends was not an
infinite loop to begin with.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Phlip]

Jack Klein wrote:

How could one infinite loop be better than another? Could one be
infinitely more infinite than the other? If one ends before the other
does, the comparison was invalid because the one that ends was not an
infinite loop to begin with.

Haw haw.

That sophistry is either a play on James Kanze's latest post to the thread
"Infinite loop == undefined behaviour?"...

http://groups.google.com/group/comp....69f9d5e793835b

....or a supernatural channeling of it, if you hadn't read it yet.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Old Wolf]

Rolf Magnus wrote:

am*********@gmail.com wrote:

char i=1;

while(i>0)
++i;

std::cout << int(i);
std::cin.get();

return 0;
}
print -128

It might do this, or it might do anything else. The overflow behavior of
signed integers is undefined.

This is actually a case of out-of-range assignment: i is promoted
to int for the expression ++i, and the result is then reassigned
to i.

[Rolf Magnus]

Old Wolf wrote:

Rolf Magnus wrote:

am*********@gmail.com wrote:

char i=1;

while(i>0)
++i;

std::cout << int(i);
std::cin.get();

return 0;
}
print -128
It might do this, or it might do anything else. The overflow behavior of
signed integers is undefined.

This is actually a case of out-of-range assignment:

<nitpick>unless char is signed and sizeof(int)==sizeof(char)</nitpick>.
i is promoted to int for the expression ++i, and the result is then
reassigned to i.

The other example that used int for i was doing what I wrote. Anyway, what
would be the behavior here? Is the value just truncated (modulo) or is it
UB too?

[Old Wolf]

Rolf Magnus wrote:

Old Wolf wrote:

am*********@gmail.com wrote:

char i=1;

while(i>0)
++i; This is actually a case of out-of-range assignment:

<nitpick>unless char is signed and sizeof(int)==sizeof(char)</nitpick>.

Of course :)
The other example that used int for i was doing what I wrote. Anyway, what
would be the behavior here? Is the value just truncated (modulo) or is it
UB too?

Being signed, I think it is a case of implementation-defined
behaviour or an i-d signal in C99. (