Blocks, or not?

Discussion in 'C Programming' started by Rob, Aug 21, 2005.

  1. Rob

    Rob Guest

    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.
     
    Rob, Aug 21, 2005
    #1
    1. Advertising

  2. Rob

    Alex Fraser Guest

    "Rob" <> wrote in message
    news:...
    > 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
     
    Alex Fraser, Aug 21, 2005
    #2
    1. Advertising

  3. 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?"
     
    Emmanuel Delahaye, Aug 21, 2005
    #3
  4. Rob

    pete Guest

    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?
    >
    > 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.

    --
    pete
     
    pete, Aug 21, 2005
    #4
  5. 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++
     
    Emmanuel Delahaye, Aug 21, 2005
    #5
  6. Rob

    SM Ryan Guest

    "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?

    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.
     
    SM Ryan, Aug 21, 2005
    #6
  7. 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?


    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.
     
    Giannis Papadopoulos, Aug 21, 2005
    #7
  8. Rob

    Guillaume Guest

    SM Ryan wrote:
    > 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...
     
    Guillaume, Aug 21, 2005
    #8
  9. Rob

    Eric Sosman Guest

    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.

    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
    lid
     
    Eric Sosman, Aug 21, 2005
    #9
  10. Rob

    CBFalconer Guest

    pete wrote:
    > 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?
    >>

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

    --
    "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
     
    CBFalconer, Aug 21, 2005
    #10
  11. >> 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.


    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
     
    Gordon Burditt, Aug 21, 2005
    #11
  12. Rob

    Malcolm Guest

    "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?
    >
    > 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.
     
    Malcolm, Aug 21, 2005
    #12
  13. Rob

    CBFalconer Guest

    Gordon Burditt wrote: (and failed to preserve attributions)
    >

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

    --
    "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
     
    CBFalconer, Aug 21, 2005
    #13
  14. Hello,

    CBFalconer <> 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.

    --
    http://www.trikaliotis.net/
     
    Spiro Trikaliotis, Aug 22, 2005
    #14
  15. 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 !

    --
    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
     
    Emmanuel Delahaye, Aug 22, 2005
    #15
  16. Rob

    John Bode Guest

    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?
    >
    > 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.
     
    John Bode, Aug 22, 2005
    #16
  17. In article <>, "Emmanuel Delahaye" <> 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

    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
     
    Michael Wojcik, Aug 22, 2005
    #17
  18. Rob

    akarl Guest

    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?
    >
    > 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
     
    akarl, Aug 23, 2005
    #18
  19. Rob

    Tim Rentsch Guest

    Eric Sosman <> writes:

    > 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.
     
    Tim Rentsch, Aug 26, 2005
    #19
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Cantley
    Replies:
    2
    Views:
    12,107
    ant177
    Dec 14, 2005
  2. Arjen
    Replies:
    3
    Views:
    453
    Scott Allen
    Feb 27, 2005
  3. Peter Rilling
    Replies:
    2
    Views:
    404
    news.microsoft.com
    Apr 5, 2005
  4. matt
    Replies:
    1
    Views:
    284
    George Ogata
    Aug 6, 2004
  5. Steven Taylor
    Replies:
    9
    Views:
    270
    Brian Candler
    Apr 27, 2009
Loading...

Share This Page