article - Guidelines for writing efficient C code

Discussion in 'C Programming' started by Marco, Apr 8, 2006.

  1. Marco

    Marco Guest

    Marco, Apr 8, 2006
    #1
    1. Advertising

  2. Marco wrote:
    > FYI:
    >
    > Guidelines for writing efficient C/C++ code
    >
    > http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >
    > any comments?


    Guideline #1: Ignore anyone who "teaches" about the mythical "C/C++"
    programming language.

    Guideline #2: Ignore anyone who thinks that guidelines for code written
    in C and guidelines for code written in C++ should be similar.
     
    Martin Ambuhl, Apr 8, 2006
    #2
    1. Advertising

  3. Marco

    Default User Guest

    Martin Ambuhl wrote:

    > Marco wrote:
    > > FYI:
    > >
    > > Guidelines for writing efficient C/C++ code
    > >
    > > http://www.embedded.com/showArticle.jhtml?articleID=184417272
    > >
    > > any comments?

    >
    > Guideline #1: Ignore anyone who "teaches" about the mythical "C/C++"
    > programming language.
    >
    > Guideline #2: Ignore anyone who thinks that guidelines for code
    > written in C and guidelines for code written in C++ should be similar.


    It should be noted that the article concerns writing code for embedded
    applications and is heavily geared towards that, not general
    programming. It's written by a guy from Green Hills, probably NOT the
    person who posted this link. As it says there:

    "This article is excerpted from a paper of the same name presented at
    the Embedded Systems Conference Silicon Valley 2006. Used with
    permission of the Embedded Systems Conference."



    Brian
     
    Default User, Apr 8, 2006
    #3
  4. Marco

    Skarmander Guest

    Marco wrote:
    > FYI:
    >
    > Guidelines for writing efficient C/C++ code
    >
    > http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >
    > any comments?
    >

    "Conclusion

    The performance impact of some decisions that programmers make when writing
    their code can be significant. While efficient algorithmic design is of the
    highest importance, making intelligent choices when implementing the design
    can help application code perform at its highest potential."

    Paragraphs like these inspire a deep admiration in me for the richness and
    vast potential of written language in communication, and an equally deep
    sadness for how easily this is squandered.

    The rest of the article is worthless (as opposed to vacuous); anyone who
    understands the reasoning behind these guidelines does not need them, and
    anyone who does not should not be put in a situation where they could apply
    them. Obviously, however, this is not factoring in reality, which is rather
    boring and depressing, and left as an exercise to the reader.

    On a less cynical note, I like tea. Unfortunately that has nothing to do
    with the article, but you can't have everything.

    S.
     
    Skarmander, Apr 8, 2006
    #4
  5. Marco

    Chris Hills Guest

    Chris Hills, Apr 8, 2006
    #5
  6. Marco

    Chris Hills Guest

    In article <GbSZf.1837$>,
    Martin Ambuhl <> writes
    >Marco wrote:
    >> FYI:
    >>
    >> Guidelines for writing efficient C/C++ code
    >>
    >> http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>
    >> any comments?

    >
    >Guideline #1: Ignore anyone who "teaches" about the mythical "C/C++"
    >programming language.
    >
    >Guideline #2: Ignore anyone who thinks that guidelines for code written
    >in C and guidelines for code written in C++ should be similar.


    I agree completely!

    There are three languages, C, C++ and "c/C++" :)

    The point is C++ was based on C90. After that point C went one way (C99)
    and C++ diverged in a different direction.

    There are parts of C99 that do not behave the same way as the C90 that
    was used in C++.


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Apr 8, 2006
    #6
  7. Marco

    Skarmander Guest

    Chris Hills wrote:
    > In article <>, Marco
    > <> writes
    >> FYI:
    >>
    >> Guidelines for writing efficient C/C++ code
    >>
    >> http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>
    >> any comments?
    >>

    > http://mistray-C.phaedsys.org
    >

    I like it very much. Especially the typos in identifiers. You don't see
    those often enough in guidelines.

    A nice exercise is to find statements in those guidelines that are not
    *completely* false. I think I saw a few.

    S.
     
    Skarmander, Apr 8, 2006
    #7
  8. Marco

    Ian Collins Guest

    Martin Ambuhl wrote:
    > Marco wrote:
    >
    >> FYI:
    >>
    >> Guidelines for writing efficient C/C++ code
    >>
    >> http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>
    >> any comments?

    >
    >
    > Guideline #1: Ignore anyone who "teaches" about the mythical "C/C++"
    > programming language.
    >

    :)

    > Guideline #2: Ignore anyone who thinks that guidelines for code written
    > in C and guidelines for code written in C++ should be similar.
    >

    There's plenty of overlaps at the low levels this paper uses.

    --
    Ian Collins.
     
    Ian Collins, Apr 9, 2006
    #8
  9. Marco

    Chris Hills Guest

    In article <44383abc$0$11069$4all.nl>, Skarmander
    <> writes
    >Chris Hills wrote:
    >> In article <>, Marco
    >> <> writes
    >>> FYI:
    >>>
    >>> Guidelines for writing efficient C/C++ code
    >>>
    >>> http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>>
    >>> any comments?
    >>>

    >> http://mistray-C.phaedsys.org
    >>

    >I like it very much. Especially the typos in identifiers. You don't see
    >those often enough in guidelines.
    >
    >A nice exercise is to find statements in those guidelines that are not
    >*completely* false. I think I saw a few.
    >
    >S.


    Oh Bugger! Let me know and I will have them replaced with suitable urban
    myths.

    I am currently working on MIStRAy C:2004 :)

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Apr 9, 2006
    #9
  10. Marco

    Michael Mair Guest

    Michael Mair, Apr 9, 2006
    #10
  11. Marco

    pete Guest

    Chris Hills wrote:
    >
    > In article <44383abc$0$11069$4all.nl>, Skarmander
    > <> writes
    > >Chris Hills wrote:
    > >> In article <>, Marco
    > >> <> writes
    > >>> FYI:
    > >>>
    > >>> Guidelines for writing efficient C/C++ code
    > >>>
    > >>> http://www.embedded.com/showArticle.jhtml?articleID=184417272
    > >>>
    > >>> any comments?


    I'm also of the opinion that one shouldn't use
    types of lower rank than int, without a special reason.
    I was going to mention it to a recent poster
    who posted a function definition with unsigned short
    (or something like ushort, I don't exactly remember)
    parameters, but I never got around to it.

    --
    pete
     
    pete, Apr 9, 2006
    #11
  12. Marco

    Charles Krug Guest

    On 2006-04-08, Marco <> wrote:
    > FYI:
    >
    > Guidelines for writing efficient C/C++ code
    >
    > http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >
    > any comments?
    >


    Embedded systems is NOT general programming and shouldn't be confused
    with it.

    When you need to get "close to the machine," all bets are off, and you
    start needing to worry about things like the exact bit width of a data
    type, including unpacked vs packed structures, how good your compiler's
    optimizer is, (or in some cases if it works at all).

    This is a Particular problem domain, that Happens often to use C, and
    occasionally c++, when it's not using Assembly.

    What it discusses is only "On Topic" in as much at it uses the
    constructs of Standard c which, being embedded code, need not be very
    "standard" at all.
     
    Charles Krug, Apr 9, 2006
    #12
  13. Marco

    Chris Hills Guest

    In article <>, pete <>
    writes
    >Chris Hills wrote:
    >>
    >> In article <44383abc$0$11069$4all.nl>, Skarmander
    >> <> writes
    >> >Chris Hills wrote:
    >> >> In article <>, Marco
    >> >> <> writes
    >> >>> FYI:
    >> >>>
    >> >>> Guidelines for writing efficient C/C++ code
    >> >>>
    >> >>> http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >> >>>
    >> >>> any comments?

    >
    >I'm also of the opinion that one shouldn't use
    >types of lower rank than int, without a special reason.



    Well, on all 8 bit micros you have to. Usually char on account of the
    fact they often don't have [any/many] 16 bit registers and the Char is
    really the native size for the part. Signed and unsigned char, of course
    are integer types.

    >I was going to mention it to a recent poster
    >who posted a function definition with unsigned short


    I don't like using shorts unless they are a real in that is between Int
    and char. They should nt be used where they are the same size as char or
    int.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Apr 10, 2006
    #13
  14. Marco

    Chris Hills Guest

    In article <>, Michael Mair
    <> writes
    >Chris Hills schrieb:
    >> In article <>, Marco
    >> <> writes
    >>>FYI:
    >>>
    >>>Guidelines for writing efficient C/C++ code
    >>>
    >>>http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>>
    >>>any comments?

    >>
    >> http://mistray-C.phaedsys.org

    >
    >Seems to be down at the moment :-/


    Hi,

    It should be back up now. Week end maintenance :-(

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Apr 10, 2006
    #14
  15. Marco

    Chris Hills Guest

    In article <>, Charles Krug
    <> writes
    >On 2006-04-08, Marco <> wrote:
    >> FYI:
    >>
    >> Guidelines for writing efficient C/C++ code
    >>
    >> http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>
    >> any comments?
    >>

    >
    >Embedded systems is NOT general programming and shouldn't be confused
    >with it.


    I agree. The number of people I see doing "IT" on embedded systems is
    getting worse.

    However "standard c" is rarely used these days. 95% of all C programming
    is going to use some extensions and deviations. From windows to Linux to
    the vast array of embedded systems.



    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Apr 10, 2006
    #15
  16. Chris Hills <> writes:
    > In article <>, pete <>
    > writes

    [...]
    >>I'm also of the opinion that one shouldn't use
    >>types of lower rank than int, without a special reason.

    >
    >
    > Well, on all 8 bit micros you have to. Usually char on account of the
    > fact they often don't have [any/many] 16 bit registers and the Char is
    > really the native size for the part. Signed and unsigned char, of course
    > are integer types.


    Which, of course, qualifies as a "special reason".

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Apr 10, 2006
    #16
  17. In article <>,
    Chris Hills <> wrote:

    >However "standard c" is rarely used these days. 95% of all C programming
    >is going to use some extensions and deviations. From windows to Linux to
    >the vast array of embedded systems.


    ``95% of all C programs'' I would be willing to believe, but a similarly
    large randomly chosen percentage of most of those programs can be written
    in standard C, with only the interface to whatever system-specific
    functionality is needed using extensions and deviations.

    I would say (making a guess at what might be a real number, rather than
    using rectal extraction to obtain an impressively large one) that probably
    75% of C code can/should be written in such a way that it would do The
    Right Thing when compiled with any sensible conforming compiler[1],
    even if it isn't done that way in practice.


    dave
    (unless you're competing with WeBuildRadar, then tie it to the system
    as closely as you can, whether there's a good reason or not)

    [1] Which is a slightly stronger condition than "is strictly conforming",
    but not by too much.

    --
    Dave Vandervies
    Yes, I've seen some of those - one was miniature elephants waving their
    trunks. I didn't think it added to readability, but that's just my opinion.
    --Alan Balmer in comp.lang.c
     
    Dave Vandervies, Apr 10, 2006
    #17
  18. Marco

    Michael Mair Guest

    Chris Hills schrieb:
    > In article <>, Michael Mair
    > <> writes
    >>Chris Hills schrieb:
    >>>In article <>, Marco
    >>><> writes
    >>>
    >>>>FYI:
    >>>>
    >>>>Guidelines for writing efficient C/C++ code
    >>>>
    >>>>http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>>>
    >>>>any comments?
    >>>
    >>>http://mistray-C.phaedsys.org

    >>
    >>Seems to be down at the moment :-/

    >
    > It should be back up now. Week end maintenance :-(


    Great! It's hilarious and terrifyingly realistic at the same
    time...

    [The following is not meant as serious guideline]

    However, you managed to not sufficiently un-restrict people's
    creativity in some points:

    I suggest more rules on (ab)using bit operations, e.g.
    - XOR swapping for efficiency
    - & and | to emulate non-shorcircuited logic operations
    - using bit operations whenever you can -- they are always faster

    In addition, a programmer should expand his or her horizon and
    abilities by making arbitrary impromptu tests like "let's see
    whether I can write this function/module without using directives
    x, y, z and operators a, b, c".

    switch followed by a compound statement gives room for
    optimizations like restricting the scope of auxiliary variables
    to this statement only, on-the-fly Duff's Device like partial
    loop unrolling etc.

    The obvious lack of mentioning gets() for the case of "knowing
    thy input" may even be seen as malicious neglect.


    Cheers ;-)
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Apr 10, 2006
    #18
  19. Marco

    Chris Hills Guest

    In article <>, Michael Mair
    <> writes
    >Chris Hills schrieb:
    >> In article <>, Michael Mair
    >> <> writes
    >>>Chris Hills schrieb:
    >>>>In article <>, Marco
    >>>><> writes
    >>>>
    >>>>>FYI:
    >>>>>
    >>>>>Guidelines for writing efficient C/C++ code
    >>>>>
    >>>>>http://www.embedded.com/showArticle.jhtml?articleID=184417272
    >>>>>
    >>>>>any comments?
    >>>>
    >>>>http://mistray-C.phaedsys.org
    >>>
    >>>Seems to be down at the moment :-/

    >>
    >> It should be back up now. Week end maintenance :-(

    >
    >Great! It's hilarious and terrifyingly realistic at the same
    >time...


    Thanks.

    I wrote the initial parts during an idle half hour in a MISRA C meeting.
    That is why it has 127 rules that mirror the MISRA rules.

    Next on my agenda is MIStRAy-c:2004 to mirror the MISRA-C:2004 but at
    the moment we are working on the TC and example suite.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Apr 10, 2006
    #19
  20. In article <e1dn53$58p$>,
    I wrote:

    >[Most] C code can/should be written in such a way that it would do The
    >Right Thing when compiled with any sensible conforming compiler[1],


    >[1] Which is a slightly stronger condition than "is strictly conforming",
    > but not by too much.


    I think I meant ``slightly weaker condition'' here, not stronger.


    dave

    --
    Dave Vandervies
    There was *one* method that checked which OS the client was running on. It
    had to select a \ or / in order to generate a proper local filename.
    --Bob Nemec in comp.lang.smalltalk
     
    Dave Vandervies, Apr 12, 2006
    #20
    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. JIT

    Code Guidelines

    JIT, Oct 4, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    526
    Rajesh Kumar
    Nov 2, 2004
  2. New
    Replies:
    11
    Views:
    802
    Chris Smith
    Jan 9, 2004
  3. gonzlobo

    Writing more efficient code

    gonzlobo, Jan 1, 2007, in forum: Python
    Replies:
    13
    Views:
    457
    Hendrik van Rooyen
    Jan 3, 2007
  4. Andrew 2006

    Guidelines for writing an XML API

    Andrew 2006, May 31, 2007, in forum: XML
    Replies:
    5
    Views:
    541
    Andrew 2006
    May 31, 2007
  5. Replies:
    5
    Views:
    323
    Roedy Green
    Jul 13, 2007
Loading...

Share This Page