Sign in to follow this  
TEUTON

writing infinite loop

Recommended Posts

This was asked from my friend in an interview. Which is a efficient way of writing an infinite loop?? I guess all are same, what do you think guys?

Share this post


Link to post
Share on other sites
I'm not sure what an "efficient" way would be to writing an infinite loop, since it is an infinite loop, but I'd guess: while(1){ } or for(;;){ } So yea, the question needs more context to make sense. (The question they asked, not you)

Share this post


Link to post
Share on other sites
Is while(true); more efficient than while(1); ?

I would guess so but im not sure, my theory is that 1 would have to evalute to true first, not sure about for(;;);

Share this post


Link to post
Share on other sites
Is while(true); more efficient than while(1); ?

I would guess so but im not sure, my theory is that 1 would have to evalute to true first, not sure about for(;;); or maybe the bool would have to change to an int type.

Share this post


Link to post
Share on other sites
Quote:
Original post by simon10k
Is while(true); more efficient than while(1); ?

I would guess so but im not sure, my theory is that 1 would have to evalute to true first, not sure about for(;;);


No. Even if true was a macro (or even a constant), it would be replaced at compile-time.

Share this post


Link to post
Share on other sites

void slow_infinite_loop()
{
double f = 0;
while(f < 1) {
f = rand_float();
f = secant(f) * cosine(f);
f /= 2.0;

//do stuff here
}
}


If the infinite loop is intentional, then chances are it won't get much faster than it already is.

CM

Share this post


Link to post
Share on other sites
Sounds like nonsense to me.

Really, it seems like the "infinite" is a complete red herring. Unrolling the loop might improve its performance, depending upon what kind of machine you're running it on. But that's also true of non-infinite loops.

Perhaps the question is designed to test if you recognise BS when you hear it. [smile] Or, alternatively, and perhaps more usefully, to test if you recognise when some part of a problem probably isn't actually relevant, like the infiniteness of the loop probably isn't relevant to its efficiency.

Share this post


Link to post
Share on other sites
It sounds like a trick question. An infinite loop should eventually compile to:
lbl:
{
// do stuff here
}
goto lbl;

Which maps 1:1 in assembly.

Share this post


Link to post
Share on other sites
This made me think that they were maybe wanting to see a "sleep(1)" or something at the end of it.

Share this post


Link to post
Share on other sites
As far as I know,
while(1) contains an extra 'cmp' in assembly than for(;;).

I've also heard using goto is more efficient (faster?) than for(;;), but I'm not sure.

Share this post


Link to post
Share on other sites
I can't resist a good waste of time sometimes ;-).

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.

As such, I can only give a psuedo-infinite loop.

while ( true ) {
...
}


Efficiency metrics:

1) Runtime performance.

Like just about any psuedo-infinite loop, the compiler should optimize it automatically into an unconditional jump.

2) Intent self-documentation

From a glance, we can tell what the conditional will evaluate to (true), and from this deduct how many loops the loop will theoretically execute (an infinite number). It does not depend on knowing language-syntax corner cases ("for (;;)") either.

3) Result self-documentation

Here this lags behind a bit. Although the loop is "infinite", odds are 100+ to 1 that it will still end at some point - server shuts down, needs a hardware upgrade/reboot, backup, or what have you. The mechanisms for exiting are out of channel data, however - exit(), exceptions, returns, and the like - all things which are not eliminated with any other loop either.

This could be made clearer by making them explicit conditions of the loop rather than relying on out-of-channel information, however. The best match in such a case will depend on what we wish to communicate, as well as what types of conditionals we're allowed to submit as "psuedo-infinite".

4) Debug efficiency

Since the loop relys only on standard language features, debuggers should have no problem coping with it's traditional scoping and semantics.

This overanalysis of JUST A #$%(*^#( SIMPLE LOOP brought to you by MaulingMonkey.

Quote:
Original post by void0
As far as I know,
while(1) contains an extra 'cmp' in assembly than for(;;).

I've also heard using goto is more efficient (faster?) than for(;;), but I'm not sure.


Not on any sane compiler, for either.

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
I can't resist a good waste of time sometimes ;-).

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.

As such, I can only give a psuedo-infinite loop.

while ( true ) {
...
}

That's just silly semantics. A loop whose terminating condition is either nonexistent (e.g. "for (;;) { ... }") or which can never be met (e.g. "while (true) { ... }") is infinite. And if we're going to get bogged down in semantics, then it behooves me to point out that we can never "reach infinity". Infinity is neither a goal you can attain nor a line you can cross.

Pseudo-infinite loops like you mentioned do exist, but they only appear to be infinite and do in fact terminate. For instance, "while (rand.Next() != 0) { ... }" is pseudo-infinite (the expected number of iterations is 232).

Share this post


Link to post
Share on other sites
It's really whatever you prefer. I always use for(;;) because using any other looping construct (while(true), do..while(1), etc) causes MSVC to complain about contstant expressions. Having said that, the first time I saw for(;;), I didn't have a clue what it was doing. I always think that while(true) is the cleanest and most obvious infinite loop.

Share this post


Link to post
Share on other sites
Fact is, you don't need to worry about making your infinite loops more efficient. It's true, it was a concern back in the days of 9-track tape reels where a real programmer knew at least three ways to approach an M-way tape merge with only M-1 tape drives (M >= 3), and knew the difference between 77 and 88 in the data division. These days, however, we can just rely on Moore's law knowing with confidence that in 18 months your infinite loop will complete in just half the time it takes today.

Share this post


Link to post
Share on other sites
Quote:

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.


How do you reach infinity?

Share this post


Link to post
Share on other sites
Quote:
Original post by cherryhouse
Quote:

A) There is no true infinite loop. Only loops that are meant to be infinite. We'll never reach there, the program will crash/have it's computer die/etc well before we reach infinity.


How do you reach infinity?


With really long arms

Share this post


Link to post
Share on other sites
Quote:
Original post by void0
I've also heard using goto is more efficient (faster?) than for(;;), but I'm not sure.


Maybe the first time K&R wrote the compiler...

Share this post


Link to post
Share on other sites
lbl: goto lbl;
works for me ;)

As for answering the OP's question, I would answer it with a question: Why would you want to write an "infinite loop".

Timkin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this