`Comparability' of code snippets (from book `Code complete')

[lovecreatesbea...]

The book `Code complete' mentions similar code snippets as the
followings , and talks about their advantages respectively.

But I think these code snippets are totally different in logic, and
their functionalities are different. They don't have comparabilities.
Am I right?


/*code 1*/
for (i = 0; i < N; i++){
if (cond)
DoSomething();
else
DoOtherthing();
}

/*code 2*/
if (cond){
for (i = 0; i < N; i++)
DoSomething();
} else {
for (i = 0; i < N; i++)
DoOtherthing();
}

 

[Richard Heathfield]

(e-mail address removed) said:

The book `Code complete' mentions similar code snippets as the
followings , and talks about their advantages respectively.

But I think these code snippets are totally different in logic, and
their functionalities are different. They don't have comparabilities.
Am I right?

It depends on details that are not shown.

 

[Malcolm McLean]

The book `Code complete' mentions similar code snippets as the
followings , and talks about their advantages respectively.

But I think these code snippets are totally different in logic, and
their functionalities are different. They don't have comparabilities.
Am I right?


/*code 1*/
for (i = 0; i < N; i++){
if (cond)
DoSomething();
else
DoOtherthing();
}

/*code 2*/
if (cond){
for (i = 0; i < N; i++)
DoSomething();
} else {
for (i = 0; i < N; i++)
DoOtherthing();
}

Assuming no attempt to alter cond, i or N in the functions, they should have
exactly the same effect.

The question is which is more efficient, and which is better style.

 

[Mark McIntyre]

The book `Code complete' mentions similar code snippets as the
followings , and talks about their advantages respectively.

But I think these code snippets are totally different in logic, and
their functionalities are different. They don't have comparabilities.
Am I right?


/*code 1*/
for (i = 0; i < N; i++){
if (cond)
DoSomething();
else
DoOtherthing();
}

/*code 2*/
if (cond){
for (i = 0; i < N; i++)
DoSomething();
} else {
for (i = 0; i < N; i++)
DoOtherthing();
}

Provided neither DoSomething() nor DoNothing() alter the value of cond
or i, they're identical, and a good optimising compiler should be able
to generate the same machinecode.

 

[santosh]

The book `Code complete' mentions similar code snippets as the
followings , and talks about their advantages respectively.

But I think these code snippets are totally different in logic, and
their functionalities are different. They don't have comparabilities.
Am I right?


/*code 1*/
for (i = 0; i < N; i++){
if (cond)
DoSomething();
else
DoOtherthing();
}

/*code 2*/
if (cond){
for (i = 0; i < N; i++)
DoSomething();
} else {
for (i = 0; i < N; i++)
DoOtherthing();
}

They have the same effect but only if 'i' and 'cond' are not altered by
either of the functions. If they are going to be volatile the first
form is the correct one.

 

[Keith Thompson]

They have the same effect but only if 'i' and 'cond' are not altered by
either of the functions. If they are going to be volatile the first
form is the correct one.

It depends on whether we want to evaluate ``cond'' just once, or once
for each iteration. We just don't have enough information to determine
which one is correct.

 

[Malcolm McLean]

It depends on whether we want to evaluate ``cond'' just once, or once for
each iteration. We just don't have enough information to determine which
one is correct.

if cond is in fact a macro that has side-effects.

But then maybe "if" has been redefined by the preprocessor, if you're going
to get like that.

 

[Tor Rustad]

The book `Code complete' mentions similar code snippets as the
followings , and talks about their advantages respectively.

But I think these code snippets are totally different in logic, and
their functionalities are different. They don't have comparabilities.
Am I right?


/*code 1*/
for (i = 0; i < N; i++){
if (cond)
DoSomething();
else
DoOtherthing();
}

/*code 2*/
if (cond){
for (i = 0; i < N; i++)
DoSomething();
} else {
for (i = 0; i < N; i++)
DoOtherthing();
}

The answer depends on weather 'cond' is a loop-invariant, or not.

The compiler can sometimes tell, and might then replace the first code
snippet with the second, during the optimizing.

 

[Keith Thompson]

if cond is in fact a macro that has side-effects.

But then maybe "if" has been redefined by the preprocessor, if you're
going to get like that.

Get like what?

You snipped part of the article to which I replied, in which santosh wrote:

They have the same effect but only if 'i' and 'cond' are not
altered by either of the functions. If they are going to be
volatile the first form is the correct one.

If "cond" is declared volatile, then the number of times it's evaluated
obviously can be relevant. It needn't be a macro.

For that matter, "cond" could be an abbreviation for the word "condition", and
could refer (in pseudo-code) to any arbitrary expression used as a condition.
It's not entirely clear whether the code was meant to be taken literally. But
even if it was, the issue is volatility.

 

[CBFalconer]

if cond is in fact a macro that has side-effects.

But then maybe "if" has been redefined by the preprocessor, if
you're going to get like that.

You can't redefine 'if' and have a legitimate program.

 

[James Kuyper]

Malcolm McLean wrote: ....

You can't redefine 'if' and have a legitimate program.

What does "legitimate program" mean, in this context? I don't believe
that redefining a keyword has undefined behavior, is a syntax error, or
violates any constraints. It's a very bad idea, but that's a different
question entirely.

 

[Barry Schwarz]

The book `Code complete' mentions similar code snippets as the
followings , and talks about their advantages respectively.

But I think these code snippets are totally different in logic, and
their functionalities are different. They don't have comparabilities.
Am I right?


/*code 1*/
for (i = 0; i < N; i++){
if (cond)
DoSomething();
else
DoOtherthing();
}

/*code 2*/
if (cond){
for (i = 0; i < N; i++)
DoSomething();
} else {
for (i = 0; i < N; i++)
DoOtherthing();
}

When cond is invariant while the loop is iterating (always true or
always false), they appear to be equivalent. Can you describe a
situation where they do not perform the same?

When cond changes over the course of the loop, they are very obviously
different. code 1 executes DoSomething or DoOtherthing depending on
the *current* state of cond while code2 executes the same function
(either DoSomething or DoOtherthing) for every iteration depending
only on the *initial* state of cond.




Remove del for email

 

[CBFalconer]

What does "legitimate program" mean, in this context? I don't
believe that redefining a keyword has undefined behavior, is a
syntax error, or violates any constraints. It's a very bad idea,
but that's a different question entirely.

I had to search a while. From N869:

6.4.1 Keywords

Syntax
[#1]
keyword: one of
auto enum restrict unsigned
break extern return void
case float short volatile
char for signed while
const goto sizeof _Bool
continue if static _Complex
default inline struct _Imaginary
do int switch
double long typedef
else register union

Semantics

[#2] The above tokens (case sensitive) are reserved (in
translation phases 7 and 8) for use as keywords, and shall
not be used otherwise.

 

[James Kuyper]

What does "legitimate program" mean, in this context? I don't
believe that redefining a keyword has undefined behavior, is a
syntax error, or violates any constraints. It's a very bad idea,
but that's a different question entirely.

I had to search a while. From N869:

6.4.1 Keywords

Syntax
[#1]
keyword: one of
auto enum restrict unsigned
break extern return void
case float short volatile
char for signed while
const goto sizeof _Bool
continue if static _Complex
default inline struct _Imaginary
do int switch
double long typedef
else register union

Semantics

[#2] The above tokens (case sensitive) are reserved (in
translation phases 7 and 8) for use as keywords, and shall
not be used otherwise.

My apologies - I should have performed the search, not you. But I was
pretty certain there was nothing to find, which tends to remove the
motivation to look.

 

[Flash Gordon]

James Kuyper wrote, On 20/11/07 05:14:

CBFalconer wrote:
Malcolm McLean wrote:
...
But then maybe "if" has been redefined by the preprocessor, if
you're going to get like that.
You can't redefine 'if' and have a legitimate program.
What does "legitimate program" mean, in this context? I don't
believe that redefining a keyword has undefined behavior, is a
syntax error, or violates any constraints. It's a very bad idea,
but that's a different question entirely.

I had to search a while. From N869:

6.4.1 Keywords

Syntax
[#1]
keyword: one of
auto enum restrict unsigned

Semantics

[#2] The above tokens (case sensitive) are reserved (in
translation phases 7 and 8) for use as keywords, and shall
not be used otherwise.

My apologies - I should have performed the search, not you. But I was
pretty certain there was nothing to find, which tends to remove the
motivation to look.

Isn't the #define and replacement handled in one of the earlier
translation phases making that section irrelevant as far as whether you
can do a #define of if?