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.

[Daniel T.]

desktop <ff*@sss.comwro te:

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**********@n ews.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] ote:

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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]