While vs nested if?

[desktop]

Are there any performance issues between:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}
if(bob2) {

//dothing
break;
}

if(bob2) {

//dothing
break;
}

run = false;

}

(I am aware that a switch could be used. But sometimes the conditions
consists of more parts and therefore a switch might not apply)
With nested ifs:
if (bob1){

//dothing
break;
} else {
if(bob2) {

//dothing
break;
} else {
if(bob2) {

//dothing
break;
}
}}
I prefer the while version event though it might be a bit unorthodox.

[Victor Bazarov]

desktop wrote:

Are there any performance issues between:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}
if(bob2) {

//dothing
break;
}

if(bob2) {

This is unreachable. You already have 'bob2' above. I assume
you meant 'bob3'.

>
//dothing
break;
}

run = false;

}

(I am aware that a switch could be used. But sometimes the conditions
consists of more parts and therefore a switch might not apply)
With nested ifs:
if (bob1){

//dothing
break;

'break' outside of any loop is a syntax error.

} else {
if(bob2) {

//dothing
break;
} else {
if(bob2) {

//dothing
break;
}
}}
I prefer the while version event though it might be a bit unorthodox.

I don't believe that "issues" can be "between". I think "issues"
can be "with" or sometimes "in". In the code you posted, however,
I see a simple issue: the former does not convey the intent. If
you intended to have a branching processing, do it. Why wrap it
into an artificial logic structure? And there is no need to nest
anything, just chain them (which is basically the same as nesting
only without curly braces):

if (bob1) {
do one
}
else if (bob2) {
do two
}
else fi (bob3) {
do three
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Guillermo Antonio Amaral Bastidas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

desktop wrote:

I prefer the while version event though it might be a bit unorthodox.

IMHO I have always preferred the nested approach for simple 2 ( max 3
level ) checks, if it's something more complicated I use a Bit Toggle
approach with `case` or `if`, I don't quite understand why you would need a
`while` like that, do you have a more clear example?

- --
Guillermo Antonio Amaral Bastidas (gamaral)
# Free & Open-source Software Advocate
# KDE Developer: gamaral
@ http://blog.guillermoamaral.com/
$ irc: gamaral@freenod e pgp: 0x5D297B74

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG8tS3xxx W3F0pe3QRArKiAJ 4/2vhLzT2l0gEVcrW wRxKpfgcK6ACfaz Ty
U0g+mOPw1LP+Gw9 XKKj30nQ=
=3Rt5
-----END PGP SIGNATURE-----

[desktop]

Victor Bazarov wrote:

desktop wrote:

>Are there any performance issues between:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}
if(bob2) {

//dothing
break;
}

if(bob2) {

This is unreachable. You already have 'bob2' above. I assume
you meant 'bob3'.

>//dothing
break;
}

run = false;

}

(I am aware that a switch could be used. But sometimes the conditions
consists of more parts and therefore a switch might not apply)
With nested ifs:
if (bob1){

//dothing
break;

'break' outside of any loop is a syntax error.

>} else {
if(bob2) {

//dothing
break;
} else {
if(bob2) {

//dothing
break;
}
}}
I prefer the while version event though it might be a bit unorthodox.

I don't believe that "issues" can be "between". I think "issues"
can be "with" or sometimes "in". In the code you posted, however,
I see a simple issue: the former does not convey the intent. If
you intended to have a branching processing, do it. Why wrap it
into an artificial logic structure? And there is no need to nest
anything, just chain them (which is basically the same as nesting
only without curly braces):

if (bob1) {
do one
}
else if (bob2) {
do two
}
else fi (bob3) {
do three
}

V

From a cosmetic point of view I still prefer the while/break version
event though your chain version is an improvement.

But maybe its better to stick with convention instead of inventing new
styles.

[Justin.SpahrSummers]

On Sep 20, 3:17 pm, desktop <[e-mail] ote:

From a cosmetic point of view I still prefer the while/break version
event though your chain version is an improvement.

But maybe its better to stick with convention instead of inventing new
styles.

At least if (and only if) you're going to insist on using your loop
structure, use something like:

do {
if (...) {
...
break;
}

if (...) {
...
break;
}
} while (0);

This way, the compiler will know without a doubt that the loop only
executes once and should optimize it out (if it's at all intelligent).

[Victor Bazarov]

desktop wrote:

Victor Bazarov wrote:

>desktop wrote:

>>Are there any performance issues between:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}
if(bob2) {

//dothing
break;
}

if(bob2) {

This is unreachable. You already have 'bob2' above. I assume
you meant 'bob3'.

>>//dothing
break;
}

run = false;

}

(I am aware that a switch could be used. But sometimes the
conditions consists of more parts and therefore a switch might not
apply)

From a cosmetic point of view I still prefer the while/break version
event though your chain version is an improvement.

What cosmetic point of view? *How* is

bool run = true;
while (run) {
// blah
break;
// blahblah
break;
run = false;
}

better than

// blah
// blahblah

_cosmetically_?

But maybe its better to stick with convention instead of inventing new
styles.

Conventions differ...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Juha Nieminen]

desktop wrote:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}
if(bob2) {

//dothing
break;
}

if(bob2) {

//dothing
break;
}

run = false;

}

I think you have done it way too complicated with that while. This
would be a bit simpler:

do
{
// the ifs
} while(false);

Probably easier for the compiler to optimize too.

if (bob1){

//dothing
break;
} else {
if(bob2) {

//dothing
break;
} else {
if(bob2) {

//dothing
break;
}
}}

You could save yourself typing many brackets by doing it like this:

if(cond1)
{
...
}
else if(cond2)
{
...
}
else if(cond3)
{
...
}

Becomes cleaner too.

[Michal Nazarewicz]

desktop <ff*@sss.comwri tes:

Are there any performance issues between:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}

if(bob2) {

//dothing
break;
}

if(bob2) {

//dothing
break;
}

run = false;

}

As far as I understood correctly I'd use:

#v+
do {
// some code
if (foo) break;
// some more code
if (bar) break;
// even more code more code
if (baz) break;
// and some final part;
} while (0);
#v-

With nested ifs:

if (bob1){
//dothing
break;
} else {

if(bob2) {

//dothing
break;
} else {
if(bob2) {

//dothing
break;
}
}}

On a second though I might misunderstood you and thus I'd use:

#v+
if {foo) {
// do something
} else if (bar) {
// do something else
} else if (baz) {
// or maybe do something completely different
}
#v-

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl >---<jid:mina86*chr ome.pl>--ooO--(_)--Ooo--

[werasm]

desktop wrote:

Are there any performance issues between:

[snip]

I seriously doubt it. The else's aren't evaluated
if any of the ifs prior evaluate to true.
I would rather think the while version is marginally
slower due to the additional evaluation for no reason
whatsoever.

Also, one often finds the performance bottlenecks
is not where you think they are. 80% of the code
execute 20% of the time, and pose no serious
performance bottleneck (I think, or might of
read somewhere), therefore don't sweat it.

Regards,

Werner

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-09-20 21:51, desktop wrote:

Are there any performance issues between:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}
if(bob2) {

//dothing
break;
}

if(bob2) {

//dothing
break;
}

run = false;

}

The way I see it this is just another way to write

if (bob1)
goto end;

if (bob2)
goto end;

if (bob3)
goto end;

end:

Of course, you do not actually use goto, but you get the same effect.
The problem is that goto is not disliked because of its syntax, but
because of its behaviour. People generally expect loops to do several
iterations, and only in special cases will they do only one, so a loop
that always do only one loop is a bit weird and might confuse readers.

As for performance, I am not sure (and it depends on the code generated
by the compiler) but I think the branch prediction hardware generally
expect the loops to do more than one iteration.

--
Erik Wikström