Blocks, or not?

R

Rob

Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block? Will a compiler optimize the former code to the
latter? Does it even need to?

The reason I ask is, I'd much prefer to go with the former code, simply
because I prefer the appearance.
 
A

Alex Fraser

Rob said:
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block?

The former may take a few microseconds longer to compile, but I doubt that
is important.
Will a compiler optimize the former code to the latter? Does it even need
to?

I would be surprised to find any compiler which generated different code for
the alternatives above.
The reason I ask is, I'd much prefer to go with the former code, simply
because I prefer the appearance.

FWIW, I would probably write:

if (!p) break;

Again, I would not expect any meaningful difference in compilation time, and
still the same code generated as for the above alternatives.

Alex
 
E

Emmanuel Delahaye

Rob wrote on 21/08/05 :
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other.

No difference.

I personnaly recommend the use of the first form, that is convenient
for debug and extensions.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"
 
P

pete

Rob said:
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block? Will a compiler optimize the former code to the
latter? Does it even need to?

The reason I ask is,
I'd much prefer to go with the former code, simply
because I prefer the appearance.

I prefer to use braces with all ifs and elses and loops.
It can make things simpler when it's time to modify the code.

Once, when modifying code, I made a mistake that could have
been avoided if I had originally written the code with braces.
I can't remember what the mistake was.
 
E

Emmanuel Delahaye

pete wrote on 21/08/05 :
Once, when modifying code, I made a mistake that could have
been avoided if I had originally written the code with braces.
I can't remember what the mistake was.

I remember this (well, sort of) :

if (c == 'a')
gotyxy(1,2); cprintf ('X');

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++
 
S

SM Ryan

# Functionally, the two following pieces of code are the same:
#
# if(p == NULL) {
#
# break;
# }
#
# if(p == NULL)
# break;
#
# However, I am wondering whether there are any performance implications
# in choosing one over the other. Is there any extra overhead created by
# defining a block? Will a compiler optimize the former code to the
# latter? Does it even need to?

A compiler using block level addressing instead of procedure level
could insert a few instructions to save and restore stack size on
block entry and exit. But I don't know if any such compilers still
exist, and even if they do, even moderate optimisation could elide
the instruction if it is a compound statement instead of a block.
 
G

Giannis Papadopoulos

Rob said:
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block? Will a compiler optimize the former code to the
latter? Does it even need to?

It makes no difference in compiled code. The compiler uses the braces to
understand where every block starts and ends... Nothing more.
The reason I ask is, I'd much prefer to go with the former code, simply
because I prefer the appearance.

Many say that you should use the former, since it is easier to read and
less error-prone in case you want to add something.

Even if it saves you only once from a mistake I believe it worths the
cost of typing 2 braces in every block...


--
one's freedom stops where others' begin

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
 
G

Guillaume

SM said:
A compiler using block level addressing instead of procedure level
could insert a few instructions to save and restore stack size on
block entry and exit.

Huh, probably not if no variable local to the block is declared.
I doubt you can find so dumb a compiler...
 
E

Eric Sosman

Rob said:
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block? Will a compiler optimize the former code to the
latter? Does it even need to?

This wins the Grand Prize for worrying about the
wrong things.

Let me put it this way: Any possible performance
difference between these two forms would be utterly
negligible. If you were concerned about differences
on this scale, you would not be writing C. Heck, you
would not be writing assembler, nor even machine code:
You would be designing your own custom chip with your
program burned into its silicon (and none of that wasteful
microcode, either).

It's like a 100-kilo dieter worrying about a weight
gain of three micrograms -- no, more like three quarks.

Get, as they say, a life.
 
C

CBFalconer

pete said:
.... snip ...

I prefer to use braces with all ifs and elses and loops.
It can make things simpler when it's time to modify the code.

Once, when modifying code, I made a mistake that could have
been avoided if I had originally written the code with braces.
I can't remember what the mistake was.

You avoid that problem if you write the braceless versions as:

if (condition) action();

i.e. in one line. You also save vertical space and make your code
more readable.
 
G

Gordon Burditt

Once, when modifying code, I made a mistake that could have
You avoid that problem if you write the braceless versions as:

if (condition) action();

i.e. in one line. You also save vertical space and make your code
more readable.

You can just as well make the mistake:

if (condition) action(); action2();

and I'll disagree that the code is more readable if either condition
or action() takes up much more horizontal space than shown above.
In other words:

if (color != NULL && color[0] != '\0') printf("A color (%s) has already been assigned to %s\n", color, objectname);

is better written on multiple lines.

Gordon L. Burditt
 
M

Malcolm

Rob said:
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block? Will a compiler optimize the former code to the
latter? Does it even need to?

The reason I ask is, I'd much prefer to go with the former code, simply
because I prefer the appearance.
The cost is two extra characters in your source, plus extra space. There
will be no difference in the compiled code.
So as far as the narrow technical issues are concerned, go with the former.

However you want to consider whether you are writing beginner's C. For a
leaner, code set out with lots of braces, lots of whitespace, and lots of
comments is easier to read, because he doesn't really know the syntax very
well. To the expert this becomes annoying.

I would write

if(!p)
break;

not to save typing or ACSII source, but because the break statement must
already be nested within a block, and to introduce an extra level of curly
braces just confuses things.
 
C

CBFalconer

Gordon Burditt wrote: (and failed to preserve attributions)
.... snip ...

You can just as well make the mistake:

if (condition) action(); action2();

and I'll disagree that the code is more readable if either condition
or action() takes up much more horizontal space than shown above.

If any line exceeds about 72 chars it should be split. The above
error should not happen, because there is no indentation to lull
the revisor. I.e. having:

if (condition)
action();

is more likely to be fouled on revision. However if you need:

if (long_winded_excruciating_conditional_expression) {
action();
}

is better written with the braces just to keep the line length
down.
 
S

Spiro Trikaliotis

Hello,

CBFalconer said:
You avoid that problem if you write the braceless versions as:

if (condition) action();

i.e. in one line. You also save vertical space and make your code
more readable.

Obviously, you never had to deal with 3rd party environments like the
Windows DDK, where many 'function calls' are actually macros (which are
not "guarded" via "do { ... } while (0)"), do you? ;)

To add to the confusion, the "what-is-a-macro, what-is-a-function"
properties are subject to change between different version of the DDK,
and even between different compile options of the DDK.

Even if you do not need this environment yourself, you or a collegue of
your might be required to take the code you wright today and use it in
the future with such an environment. I'd like to tell: Have fun! :)

Regards,
Spiro.
 
J

John Bode

Rob said:
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block? Will a compiler optimize the former code to the
latter? Does it even need to?

The reason I ask is, I'd much prefer to go with the former code, simply
because I prefer the appearance.

I would be surprised (nay, astonished) if there were a runtime
performance difference between the two, but I've learned to never say
never when it comes to things like this. I wouldn't worry about it,
though.

My personal bias is to put everything in a compound statement, whether
it actually contains more than one statement or not, just because I've
been bitten too many times in the past by the

if (a)
b; c;

bug. And I prefer my code to have a little vertical breathing space;
it just makes it easier for *me* to read.
 
M

Michael Wojcik

Spiro Trikaliotis wrote on 22/08/05 :

Good point !

Unfortunately, it is equivalent to the thesis "You may encounter
problems if you use headers written by idiots", which ought to be
patently obvious; and as such is not particularly informative or
useful.

Clearly, if you are working in an environment where inobvous macros
with nasty syntatic or semantic side effects have been defined,
pretty much any coding practice could be dangerous.

--
Michael Wojcik (e-mail address removed)

An intense imaginative activity accompanied by a psychological and moral
passivity is bound eventually to result in a curbing of the growth to
maturity and in consequent artistic repetitiveness and stultification.
-- D. S. Savage
 
A

akarl

Rob said:
Functionally, the two following pieces of code are the same:

if(p == NULL) {

break;
}

if(p == NULL)
break;

However, I am wondering whether there are any performance implications
in choosing one over the other. Is there any extra overhead created by
defining a block? Will a compiler optimize the former code to the
latter? Does it even need to?

The reason I ask is, I'd much prefer to go with the former code, simply
because I prefer the appearance.

As others have pointed out, the difference in terms of efficiency is
negligible.

As far as I know, all languages in the Pascal tradition after Pascal do
require explicit termination of control statements (we're talking 1970's
here). What seemed to be a good idea at first -- the distinction between
statements and statement sequences in control statements (e.g. Algol,
Pascal and C) -- turned out not to be, so I see no reason why ANSI/ISO
never decided to make braces mandatory in C.

As I see it, the advantages of explicit control statement termination are:

* Bugs are avoided (multiple statements on one line, the classical
else-if situation, wrong indentation...)

* If you use braces only when necessary, you have to decide if they are
required or not at every control statement you write. If you add one
statement to a single statement you have to add the braces, and if you
remove one of two statements you probably want to remove the braces as
well to achieve consistency throughout the code. This requires some
extra editing. Since all choices in programming are distracting, the
irrelevant ones should be removed.

* With explicit control statement termination the language gets less
complicated and more regular.


Disadvantage:

* The code gets somewhat more cluttered and slightly less readable in
case of short control statements.


August
 
T

Tim Rentsch

Eric Sosman said:
This wins the Grand Prize for worrying about the
wrong things.


Eric, please consult the Awards Committee. In this case it
seems more appropriate to award the Grand Prize for
wondering whether to worry about the wrong thing. That's
not nearly so prestigious an award.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top