What's the purpose of “for(;;)” [duplicate]
3
This question already has an answer here:
Endless loop in C/C++ [closed]
12 answers
In an old codebase, I found the following snippet:
for(;;){
// code that manipulates a vector 'vec'
if(vec.empty()) break;
}
Is there any purpose or convention behind using for(;;) instead of while(true), except for personal taste of the respective author?
c++
asked Nov 21 '18 at 13:46
Michael
3,05712149
marked as duplicate by Hans Passant, liliscent, StoryTeller c++
Users with the c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 21 '18 at 15:47
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
|
show 1 more comment
3
This question already has an answer here:
Endless loop in C/C++ [closed]
12 answers
In an old codebase, I found the following snippet:
for(;;){
// code that manipulates a vector 'vec'
if(vec.empty()) break;
}
Is there any purpose or convention behind using for(;;) instead of while(true), except for personal taste of the respective author?
c++
asked Nov 21 '18 at 13:46
Michael
3,05712149
marked as duplicate by Hans Passant, liliscent, StoryTeller c++
Users with the c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 21 '18 at 15:47
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
1
Nope, these days it's just personal taste.
– Some programmer dude
Nov 21 '18 at 13:48
4
Four keys less to press :-)
– axiac
Nov 21 '18 at 13:48
And then there's this stackoverflow.com/questions/224138/infinite-loops-top-or-bottom
– StoryTeller
Nov 21 '18 at 13:48
3
I remember seeingwhile (true)throwing a warning regarding conditional depending on constant expression (or something similar), while using some compiler, wherefor (;;)wouldn't do that.
– Algirdas Preidžius
Nov 21 '18 at 13:49
3
Canonical: stackoverflow.com/questions/20186809/endless-loop-in-c-c
– Hans Passant
Nov 21 '18 at 13:52
|
show 1 more comment
3
3
3
1
This question already has an answer here:
Endless loop in C/C++ [closed]
12 answers
In an old codebase, I found the following snippet:
for(;;){
// code that manipulates a vector 'vec'
if(vec.empty()) break;
}
Is there any purpose or convention behind using for(;;) instead of while(true), except for personal taste of the respective author?
c++
asked Nov 21 '18 at 13:46
Michael
3,05712149
This question already has an answer here:
Endless loop in C/C++ [closed]
12 answers
In an old codebase, I found the following snippet:
for(;;){
// code that manipulates a vector 'vec'
if(vec.empty()) break;
}
Is there any purpose or convention behind using for(;;) instead of while(true), except for personal taste of the respective author?
This question already has an answer here:
Endless loop in C/C++ [closed]
12 answers
c++
c++
asked Nov 21 '18 at 13:46
Michael
3,05712149
asked Nov 21 '18 at 13:46
Michael
3,05712149
asked Nov 21 '18 at 13:46
Michael
3,05712149
asked Nov 21 '18 at 13:46
Michael
3,05712149
asked Nov 21 '18 at 13:46
Michael
3,05712149
3,05712149
marked as duplicate by Hans Passant, liliscent, StoryTeller c++
Users with the c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 21 '18 at 15:47
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Hans Passant, liliscent, StoryTeller c++
Users with the c++ badge can single-handedly close c++ questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 21 '18 at 15:47
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
1
Nope, these days it's just personal taste.
– Some programmer dude
Nov 21 '18 at 13:48
4
Four keys less to press :-)
– axiac
Nov 21 '18 at 13:48
And then there's this stackoverflow.com/questions/224138/infinite-loops-top-or-bottom
– StoryTeller
Nov 21 '18 at 13:48
3
I remember seeingwhile (true)throwing a warning regarding conditional depending on constant expression (or something similar), while using some compiler, wherefor (;;)wouldn't do that.
– Algirdas Preidžius
Nov 21 '18 at 13:49
3
Canonical: stackoverflow.com/questions/20186809/endless-loop-in-c-c
– Hans Passant
Nov 21 '18 at 13:52
|
show 1 more comment
1
Nope, these days it's just personal taste.
– Some programmer dude
Nov 21 '18 at 13:48
4
Four keys less to press :-)
– axiac
Nov 21 '18 at 13:48
And then there's this stackoverflow.com/questions/224138/infinite-loops-top-or-bottom
– StoryTeller
Nov 21 '18 at 13:48
3
I remember seeingwhile (true)throwing a warning regarding conditional depending on constant expression (or something similar), while using some compiler, wherefor (;;)wouldn't do that.
– Algirdas Preidžius
Nov 21 '18 at 13:49
3
Canonical: stackoverflow.com/questions/20186809/endless-loop-in-c-c
– Hans Passant
Nov 21 '18 at 13:52
1
1
Nope, these days it's just personal taste.
– Some programmer dude
Nov 21 '18 at 13:48
Nope, these days it's just personal taste.
– Some programmer dude
Nov 21 '18 at 13:48
4
4
Four keys less to press :-)
– axiac
Nov 21 '18 at 13:48
Four keys less to press :-)
– axiac
Nov 21 '18 at 13:48
And then there's this stackoverflow.com/questions/224138/infinite-loops-top-or-bottom
– StoryTeller
Nov 21 '18 at 13:48
And then there's this stackoverflow.com/questions/224138/infinite-loops-top-or-bottom
– StoryTeller
Nov 21 '18 at 13:48
3
3
I remember seeing
while (true) throwing a warning regarding conditional depending on constant expression (or something similar), while using some compiler, where for (;;) wouldn't do that.– Algirdas Preidžius
Nov 21 '18 at 13:49
I remember seeing
while (true) throwing a warning regarding conditional depending on constant expression (or something similar), while using some compiler, where for (;;) wouldn't do that.– Algirdas Preidžius
Nov 21 '18 at 13:49
3
3
Canonical: stackoverflow.com/questions/20186809/endless-loop-in-c-c
– Hans Passant
Nov 21 '18 at 13:52
Canonical: stackoverflow.com/questions/20186809/endless-loop-in-c-c
– Hans Passant
Nov 21 '18 at 13:52
|
show 1 more comment
2 Answers
2
active
oldest
votes
9
Older C++ compilers would not issue a warning for for(;;) but they would for while(true). Ditto for C, but with while(1).
Thus the convention stuck.
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
1
Interesting - presumably some "condition always evaluates to true" warning "inherited" from more complex expressions and not given a special case in the way that a totally empty condition (permissible only for afor) apparently was.
– Lightness Races in Orbit
Nov 21 '18 at 13:51
1
I'm not sure what should constitute a bug fix for such a compiler
– StoryTeller
Nov 21 '18 at 13:51
1
This is a good historical perspective. If you add that the statements are semantically equivalent, QoI aside, I'll just delete my answer as redundant
– Lightness Races in Orbit
Nov 21 '18 at 13:51
According to the accepted answer linked by Hans Passant in comments, the reasonfor(;;)is legal code is that the empty second expression is replaced by a nonzero constant. Presumably the compiler that makes that replacement assumes that it is intentional on the part of the programmer, which is why no diagnostic is issued.
– Tim Randall
Nov 21 '18 at 14:02
@TimRandall: Methinks it's simpler than that: the "expressions" in theforloop (or whatever they are called these days), can be optionally present or absent leading to 8 different possibilities. Deciding on which combinations would yield warnings would have been tedious, particularly in the old days.
– Bathsheba
Nov 21 '18 at 14:05
|
show 1 more comment
3
No.
It is personal taste only.
It is entirely equivalent to a while (true).
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
9
Older C++ compilers would not issue a warning for for(;;) but they would for while(true). Ditto for C, but with while(1).
Thus the convention stuck.
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
1
Interesting - presumably some "condition always evaluates to true" warning "inherited" from more complex expressions and not given a special case in the way that a totally empty condition (permissible only for afor) apparently was.
– Lightness Races in Orbit
Nov 21 '18 at 13:51
1
I'm not sure what should constitute a bug fix for such a compiler
– StoryTeller
Nov 21 '18 at 13:51
1
This is a good historical perspective. If you add that the statements are semantically equivalent, QoI aside, I'll just delete my answer as redundant
– Lightness Races in Orbit
Nov 21 '18 at 13:51
According to the accepted answer linked by Hans Passant in comments, the reasonfor(;;)is legal code is that the empty second expression is replaced by a nonzero constant. Presumably the compiler that makes that replacement assumes that it is intentional on the part of the programmer, which is why no diagnostic is issued.
– Tim Randall
Nov 21 '18 at 14:02
@TimRandall: Methinks it's simpler than that: the "expressions" in theforloop (or whatever they are called these days), can be optionally present or absent leading to 8 different possibilities. Deciding on which combinations would yield warnings would have been tedious, particularly in the old days.
– Bathsheba
Nov 21 '18 at 14:05
|
show 1 more comment
9
Older C++ compilers would not issue a warning for for(;;) but they would for while(true). Ditto for C, but with while(1).
Thus the convention stuck.
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
1
Interesting - presumably some "condition always evaluates to true" warning "inherited" from more complex expressions and not given a special case in the way that a totally empty condition (permissible only for afor) apparently was.
– Lightness Races in Orbit
Nov 21 '18 at 13:51
1
I'm not sure what should constitute a bug fix for such a compiler
– StoryTeller
Nov 21 '18 at 13:51
1
This is a good historical perspective. If you add that the statements are semantically equivalent, QoI aside, I'll just delete my answer as redundant
– Lightness Races in Orbit
Nov 21 '18 at 13:51
According to the accepted answer linked by Hans Passant in comments, the reasonfor(;;)is legal code is that the empty second expression is replaced by a nonzero constant. Presumably the compiler that makes that replacement assumes that it is intentional on the part of the programmer, which is why no diagnostic is issued.
– Tim Randall
Nov 21 '18 at 14:02
@TimRandall: Methinks it's simpler than that: the "expressions" in theforloop (or whatever they are called these days), can be optionally present or absent leading to 8 different possibilities. Deciding on which combinations would yield warnings would have been tedious, particularly in the old days.
– Bathsheba
Nov 21 '18 at 14:05
|
show 1 more comment
9
9
9
Older C++ compilers would not issue a warning for for(;;) but they would for while(true). Ditto for C, but with while(1).
Thus the convention stuck.
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
Older C++ compilers would not issue a warning for for(;;) but they would for while(true). Ditto for C, but with while(1).
Thus the convention stuck.
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
answered Nov 21 '18 at 13:50
Bathsheba
175k27247370
175k27247370
1
Interesting - presumably some "condition always evaluates to true" warning "inherited" from more complex expressions and not given a special case in the way that a totally empty condition (permissible only for afor) apparently was.
– Lightness Races in Orbit
Nov 21 '18 at 13:51
1
I'm not sure what should constitute a bug fix for such a compiler
– StoryTeller
Nov 21 '18 at 13:51
1
This is a good historical perspective. If you add that the statements are semantically equivalent, QoI aside, I'll just delete my answer as redundant
– Lightness Races in Orbit
Nov 21 '18 at 13:51
According to the accepted answer linked by Hans Passant in comments, the reasonfor(;;)is legal code is that the empty second expression is replaced by a nonzero constant. Presumably the compiler that makes that replacement assumes that it is intentional on the part of the programmer, which is why no diagnostic is issued.
– Tim Randall
Nov 21 '18 at 14:02
@TimRandall: Methinks it's simpler than that: the "expressions" in theforloop (or whatever they are called these days), can be optionally present or absent leading to 8 different possibilities. Deciding on which combinations would yield warnings would have been tedious, particularly in the old days.
– Bathsheba
Nov 21 '18 at 14:05
|
show 1 more comment
1
Interesting - presumably some "condition always evaluates to true" warning "inherited" from more complex expressions and not given a special case in the way that a totally empty condition (permissible only for afor) apparently was.
– Lightness Races in Orbit
Nov 21 '18 at 13:51
1
I'm not sure what should constitute a bug fix for such a compiler
– StoryTeller
Nov 21 '18 at 13:51
1
This is a good historical perspective. If you add that the statements are semantically equivalent, QoI aside, I'll just delete my answer as redundant
– Lightness Races in Orbit
Nov 21 '18 at 13:51
According to the accepted answer linked by Hans Passant in comments, the reasonfor(;;)is legal code is that the empty second expression is replaced by a nonzero constant. Presumably the compiler that makes that replacement assumes that it is intentional on the part of the programmer, which is why no diagnostic is issued.
– Tim Randall
Nov 21 '18 at 14:02
@TimRandall: Methinks it's simpler than that: the "expressions" in theforloop (or whatever they are called these days), can be optionally present or absent leading to 8 different possibilities. Deciding on which combinations would yield warnings would have been tedious, particularly in the old days.
– Bathsheba
Nov 21 '18 at 14:05
1
1
Interesting - presumably some "condition always evaluates to true" warning "inherited" from more complex expressions and not given a special case in the way that a totally empty condition (permissible only for a
for) apparently was.– Lightness Races in Orbit
Nov 21 '18 at 13:51
Interesting - presumably some "condition always evaluates to true" warning "inherited" from more complex expressions and not given a special case in the way that a totally empty condition (permissible only for a
for) apparently was.– Lightness Races in Orbit
Nov 21 '18 at 13:51
1
1
I'm not sure what should constitute a bug fix for such a compiler
– StoryTeller
Nov 21 '18 at 13:51
I'm not sure what should constitute a bug fix for such a compiler
– StoryTeller
Nov 21 '18 at 13:51
1
1
This is a good historical perspective. If you add that the statements are semantically equivalent, QoI aside, I'll just delete my answer as redundant
– Lightness Races in Orbit
Nov 21 '18 at 13:51
This is a good historical perspective. If you add that the statements are semantically equivalent, QoI aside, I'll just delete my answer as redundant
– Lightness Races in Orbit
Nov 21 '18 at 13:51
According to the accepted answer linked by Hans Passant in comments, the reason
for(;;) is legal code is that the empty second expression is replaced by a nonzero constant. Presumably the compiler that makes that replacement assumes that it is intentional on the part of the programmer, which is why no diagnostic is issued.– Tim Randall
Nov 21 '18 at 14:02
According to the accepted answer linked by Hans Passant in comments, the reason
for(;;) is legal code is that the empty second expression is replaced by a nonzero constant. Presumably the compiler that makes that replacement assumes that it is intentional on the part of the programmer, which is why no diagnostic is issued.– Tim Randall
Nov 21 '18 at 14:02
@TimRandall: Methinks it's simpler than that: the "expressions" in the
for loop (or whatever they are called these days), can be optionally present or absent leading to 8 different possibilities. Deciding on which combinations would yield warnings would have been tedious, particularly in the old days.– Bathsheba
Nov 21 '18 at 14:05
@TimRandall: Methinks it's simpler than that: the "expressions" in the
for loop (or whatever they are called these days), can be optionally present or absent leading to 8 different possibilities. Deciding on which combinations would yield warnings would have been tedious, particularly in the old days.– Bathsheba
Nov 21 '18 at 14:05
|
show 1 more comment
3
No.
It is personal taste only.
It is entirely equivalent to a while (true).
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
add a comment |
3
No.
It is personal taste only.
It is entirely equivalent to a while (true).
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
add a comment |
3
3
3
No.
It is personal taste only.
It is entirely equivalent to a while (true).
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
No.
It is personal taste only.
It is entirely equivalent to a while (true).
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
answered Nov 21 '18 at 13:49
Lightness Races in Orbit
284k51460779
284k51460779
add a comment |
add a comment |
1
Nope, these days it's just personal taste.
– Some programmer dude
Nov 21 '18 at 13:48
4
Four keys less to press :-)
– axiac
Nov 21 '18 at 13:48
And then there's this stackoverflow.com/questions/224138/infinite-loops-top-or-bottom
– StoryTeller
Nov 21 '18 at 13:48
3
I remember seeing
while (true)throwing a warning regarding conditional depending on constant expression (or something similar), while using some compiler, wherefor (;;)wouldn't do that.– Algirdas Preidžius
Nov 21 '18 at 13:49
3
Canonical: stackoverflow.com/questions/20186809/endless-loop-in-c-c
– Hans Passant
Nov 21 '18 at 13:52