Blocks, or not?
Rob
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.
Alex Fraser
news:1124630336.7...@g49g2000cwa.googlegroups.com...
> 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
Emmanuel Delahaye
> 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?"
pete
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.
--
pete
Emmanuel Delahaye
> 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++
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.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
We found a loophole; they can't keep us out anymore.
Giannis Papadopoulos
> 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.
Guillaume
> 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...
Eric Sosman
> 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.
--
Eric Sosman
eso...@acm-dot-org.invalid
CBFalconer
> Rob wrote:
>>
>> 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?
>>
>
> 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.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Gordon Burditt
>> 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.
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
Malcolm
"Rob" <iousw...@hotmail.com> wrote
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.
CBFalconer
>
... snip ...
>>
>> 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.
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.
Spiro Trikaliotis
CBFalconer <cbfal...@yahoo.com> wrote:
> 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.
Emmanuel Delahaye
> 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? ;)
Good point !
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
.sig under repair
John Bode
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.
Michael Wojcik
In article <mn.b31c7d584...@YOURBRAnoos.fr>, "Emmanuel Delahaye" <em...@YOURBRAnoos.fr> writes:
> Spiro Trikaliotis wrote on 22/08/05 :
> > 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? ;)
>
> 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 michael...@microfocus.com
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
akarl
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
Tim Rentsch
> Rob wrote:
> > 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.
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.