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@freenode pgp: 0x5D297B74

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

iD8DBQFG8tS3xxxW3F0pe3QRArKiAJ4/2vhLzT2l0gEVcrWwRxKpfgcK6ACfazTy
U0g+mOPw1LP+Gw9XKKj30nQ=
=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]:

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.comwrites:

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*chrome.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

[Daniel T.]

desktop <ff*@sss.comwrote:

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.

Would you program "hello world" like this?

int main() {
bool done = false;
while ( !done ) {
cout << "hello world\n";
done = true;
}
}

or would you find the extra, pointless, structure silly?

[Jerry Coffin]

In article <fc**********@news.net.uni-c.dk>, ff*@sss.com says...

Are there any performance issues between:

bool run = true;
while(run) {

if (bob1 &&){

//dothing
break;
}

[ ... ]

run = false;

}

I'd advise against this, but if you're going to do something along this
line, I'd at least use something like:

do {
if (case1)
whatever();
break;

// ...
} while(0);

This obfuscates the intent to a considerably lesser degree -- in fact,
you'll find do...while(0) in a fair number of macros.

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

When you're faced with a more complex set of conditions, you can
sometimes move the conditions out into a separate function, have it
produce a simple return, and base the switch on that. This doesn't
always make sense, but can at times.

With nested ifs:
if (bob1){

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

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

Presumably you meant bob3.

//dothing
break;
}
}}

You can simplify this a bit, to something like:

if (bob1) {
whatever();
} else if (bob2) {
whatever2();
} else if (bob3) {
whatever3();
}

Depending on the situation, it can also make sense to encode bob1, bob2
and bob3 into functions (or functors), and then do something like:

typedef bool (*pred)(int);

pred predicates[] = {bob1, bob2, bob3};

for (int i=0; i<3; i++)
if (predicates[i](whatever_data) {
whatever(i);
break;
}

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Sep 20, 9:51 pm, desktop <[e-mail]:

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 performance of people trying to read your code will suffer
horribly from something like this. The canonical form is:

if ( bob1 ) {
// ...
} else if ( bob2 ) {
// ...
} else if ( bob3 ) {
// ...
}

Obviously, the position of the braces will vary according to
local conventions; some local conventions even allow omitting
them if the if only controls a single statement. But except for
the possible omission of the braces, the token sequence should
be as above.

(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;
}
}}

Conventionally, "else if" is treated as if it were a specific
keyword in itself. The grammar of C++ allows this (and in
languages where it doesn't work, such as Ada, there is always an
elseif/elsif/elif keyword).

This is *the* universal convention. Anything else is
obfuscation.

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

Not just unorthodox. Pure obfuscation, which will confuse
anyone trying to read your code. ("while" means a loop. If you
use "while" when you can't loop, you're lying to the reader.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]