C/C++ guidelines

Discussion in 'C Programming' started by Robbie Marshall, Sep 15, 2007.

  1. Hi groups,

    I'm about to embark on a new project and for maximum portability we've
    been asked to code it in the common subset of C and C++.

    Can anyone suggest any good documents that might help us? Lists of
    gotchas to avoid, that sort of thing?

    TIA!

    Robbie
     
    Robbie Marshall, Sep 15, 2007
    #1
    1. Advertising

  2. Robbie Marshall

    Ian Collins Guest

    Robbie Marshall wrote:
    > Hi groups,
    >
    > I'm about to embark on a new project and for maximum portability we've
    > been asked to code it in the common subset of C and C++.
    >

    For maximum portability, code in C89.

    If you aren't aware of the (sometimes subtle) differences between C and
    C++ (even within the common subset), don't risk running into them! Even
    when using the common subset, there are idiomatic differences between
    the two.

    --
    Ian Collins.
     
    Ian Collins, Sep 15, 2007
    #2
    1. Advertising

  3. In article <>,
    Ian Collins <> wrote:

    >> I'm about to embark on a new project and for maximum portability we've
    >> been asked to code it in the common subset of C and C++.


    >For maximum portability, code in C89.


    That's not enough: for example you need to avoid C++ keywords
    ("namespace" is one I've run into).

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Sep 15, 2007
    #3
  4. Robbie Marshall

    Guest

    On 2007-09-15, Robbie Marshall <> wrote:
    > Hi groups,
    >
    > I'm about to embark on a new project and for maximum portability we've
    > been asked to code it in the common subset of C and C++.
    >
    > Can anyone suggest any good documents that might help us? Lists of
    > gotchas to avoid, that sort of thing?
    >


    Could you give us a little more context? Why do you want to program in the
    subset of both languages? It seems to me that's a bit of a waste. You're trying
    to write code in a language that's not really standard, if you want long term
    comaptibility you should take a standardized language and go for it. If you're
    willing to take a subset of C++ and C, you might as well just program in plain
    C. If you need to you can easily import your C functions in C++ using extern
    "C".

    I don't really know how to answer your questions, i.e. I don't know any
    documentation on writting code in a subset of C and C++. But I really feel you
    should rethink what you want to do, and if you don't feel the same way I'm
    really curious to know why you don't agree with me.
     
    , Sep 15, 2007
    #4
  5. * Robbie Marshall:
    >
    > I'm about to embark on a new project and for maximum portability we've
    > been asked to code it in the common subset of C and C++.
    >
    > Can anyone suggest any good documents that might help us? Lists of
    > gotchas to avoid, that sort of thing?


    Coding in a common subset of C and C++ is a gotcha.

    C and C++ are two different languages, where some constructs that are
    valid in both mean different things. Recommended coding style therefore
    differs. E.g, in C you should not cast the result of malloc, because
    doing that might introduce subtle errors, while in C++ you must.

    Inform your manager.

    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Sep 15, 2007
    #5
  6. Robbie Marshall

    Karl Heinze Guest

    On Sun, 16 Sep 2007 00:59:47 +0200, "Alf P. Steinbach"
    <> wrote:

    >
    > [...] in C you should not cast the result of malloc, because
    > doing that might introduce subtle errors [...]
    >

    For example?


    K. H.

    --

    E-mail: info<at>simple-line<Punkt>de
     
    Karl Heinze, Sep 16, 2007
    #6
  7. "Karl Heinze" <nomail@invalid> wrote in message
    news:...
    > On Sun, 16 Sep 2007 00:59:47 +0200, "Alf P. Steinbach"
    > <> wrote:
    >> [...] in C you should not cast the result of malloc, because
    >> doing that might introduce subtle errors [...]
    >>

    > For example?


    http://c-faq.com/malloc/mallocnocast.html
     
    Chris Thomasson, Sep 16, 2007
    #7
  8. Robbie Marshall

    Karl Heinze Guest

    On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
    <> wrote:

    >
    > http://c-faq.com/malloc/mallocnocast.html
    >

    Thanx. Though I don't buy in that "argument".

    Consider:

    #include <stdio.h>

    int main(void)
    {
    char *p = (char *) malloc(10);

    return 0;
    }

    At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.

    Same with Pelles C: "Missing prototype for 'malloc'".

    Same with gcc: "implicit declaration of function 'malloc'".


    So _my_ "A:" is: There's NOTHING wrong with casting malloc's return
    value. (But don't forget to include <stdlib.h>, man!)

    Moreover: From the answer in the FAQ I deduce that the claim

    "... in C you should not cast the result of malloc,
    because doing that might introduce subtle errors [...]"

    is simply wrong: It's not the usage of the cast (as such) which "might
    introduce subtle errors. Not including <stdlib.h> is what actually
    might introduce subtle errors - but (as it seems) most modern
    compilers would catch that lapse (and produce a warning).


    K. H.

    --

    E-mail: info<at>simple-line<Punkt>de
     
    Karl Heinze, Sep 16, 2007
    #8
  9. Robbie Marshall

    Ark Khasin Guest

    Richard Tobin wrote:
    > In article <>,
    > Ian Collins <> wrote:
    >
    >>> I'm about to embark on a new project and for maximum portability we've
    >>> been asked to code it in the common subset of C and C++.

    >
    >> For maximum portability, code in C89.

    >
    > That's not enough: for example you need to avoid C++ keywords
    > ("namespace" is one I've run into).


    Is it safe to code in C89/90/94 (corrigenda) and compile, or better yet
    lint as C++ AND C?
    Is it the same labor as to to write in a common subset of British and
    American and other flavors of English?
    --
    Ark
     
    Ark Khasin, Sep 16, 2007
    #9
  10. Robbie Marshall

    Phlip Guest

    Robbie Marshall wrote:

    > I'm about to embark on a new project and for maximum portability we've
    > been asked to code it in the common subset of C and C++.


    For maximum portability, write unit tests for all your code. Then you can
    run the tests on each target platform.

    For _real_ portability (not just "tell our boss we are portable"
    portability), you could configure a test server on each target platform. Run
    the test suite each time you integrate, automatically on each platform.
    Configure them to e-mail all the developers if the tests break on any
    platform.

    Yes, I've done this before...

    --
    Phlip
    http://www.oreilly.com/catalog/9780596510657/
    "Test Driven Ajax (on Rails)"
    assert_xpath, assert_javascript, & assert_ajax
     
    Phlip, Sep 16, 2007
    #10
  11. Robbie Marshall

    Phlip Guest

    Wade Ward wrote:

    >> Yes, I've done this before...


    > I think the common subset of c and c++ is empty, because if you do malloc
    > then yikes and if you don't malloc, well that's not much of a program is
    > it.


    Actually I haven't done the Common Subset thing.

    But (char*)malloc(..) is well-formed C++ (with appropriate substitution for
    ....). Don't sweat the details; portability is up to your compiler(s).

    --
    Phlip
    http://www.oreilly.com/catalog/9780596510657/
    "Test Driven Ajax (on Rails)"
    assert_xpath, assert_javascript, & assert_ajax
     
    Phlip, Sep 16, 2007
    #11
  12. Robbie Marshall

    CBFalconer Guest

    Karl Heinze wrote:
    > "Alf P. Steinbach" <> wrote:
    >
    > > [...] in C you should not cast the result of malloc, because
    > > doing that might introduce subtle errors [...]

    >
    > For example?


    Failure to #include <stdlib.h> going undetected.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Sep 16, 2007
    #12
  13. Robbie Marshall

    CBFalconer Guest

    Phlip wrote:
    > Wade Ward wrote:
    >
    >>> Yes, I've done this before...

    >
    >> I think the common subset of c and c++ is empty, because if you
    >> do malloc then yikes and if you don't malloc, well that's not
    >> much of a program is it.

    >
    > Actually I haven't done the Common Subset thing.
    >
    > But (char*)malloc(..) is well-formed C++ (with appropriate
    > substitution for ...). Don't sweat the details; portability is up
    > to your compiler(s).


    And it is execreble dangerous coding in C. The languages are
    different. This is c.l.c, and c.l.c++ is a separate newsgroup
    dealing with a separate language. F'ups set.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Sep 16, 2007
    #13
  14. Robbie Marshall

    Wade Ward Guest

    "Phlip" <> wrote in message
    news:...
    > Robbie Marshall wrote:
    >
    >> I'm about to embark on a new project and for maximum portability we've
    >> been asked to code it in the common subset of C and C++.

    >
    > For maximum portability, write unit tests for all your code. Then you can
    > run the tests on each target platform.
    >
    > For _real_ portability (not just "tell our boss we are portable"
    > portability), you could configure a test server on each target platform.
    > Run the test suite each time you integrate, automatically on each
    > platform. Configure them to e-mail all the developers if the tests break
    > on any platform.
    >
    > Yes, I've done this before...

    I think the common subset of c and c++ is empty, because if you do malloc
    then yikes and if you don't malloc, well that's not much of a program is it.
    --
    Wade Ward

    'Wheat is for man.'
    --Joseph Smith>
     
    Wade Ward, Sep 16, 2007
    #14
  15. Robbie Marshall

    Flash Gordon Guest

    Ark Khasin wrote, On 16/09/07 02:40:
    > Richard Tobin wrote:
    >> In article <>,
    >> Ian Collins <> wrote:
    >>
    >>>> I'm about to embark on a new project and for maximum portability we've
    >>>> been asked to code it in the common subset of C and C++.

    >>
    >>> For maximum portability, code in C89.

    >>
    >> That's not enough: for example you need to avoid C++ keywords
    >> ("namespace" is one I've run into).

    >
    > Is it safe to code in C89/90/94 (corrigenda) and compile, or better yet
    > lint as C++ AND C?


    No. Since some code which is well formed in both languages will do
    different things in the two languages. We have has some such examples
    posted in comp.lang.c in the past week.

    > Is it the same labor as to to write in a common subset of British and
    > American and other flavors of English?


    The common subset changes.
    --
    Flash Gordon
     
    Flash Gordon, Sep 16, 2007
    #15
  16. Robbie Marshall <> writes:
    > I'm about to embark on a new project and for maximum portability we've
    > been asked to code it in the common subset of C and C++.
    >
    > Can anyone suggest any good documents that might help us? Lists of
    > gotchas to avoid, that sort of thing?


    Consider programming in C90 and making sure not to accidentally use a
    C++ compiler. You can enforce this with:

    #ifdef __cplusplus
    #error "Use a C compiler, not a C++ compiler"
    #endif

    --
    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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 16, 2007
    #16
  17. On 2007-09-16 03:16, CBFalconer <> wrote:
    > Phlip wrote:
    >> Wade Ward wrote:
    >>
    >>>> Yes, I've done this before...

    >>
    >>> I think the common subset of c and c++ is empty, because if you
    >>> do malloc then yikes and if you don't malloc, well that's not
    >>> much of a program is it.

    >>
    >> Actually I haven't done the Common Subset thing.
    >>
    >> But (char*)malloc(..) is well-formed C++ (with appropriate
    >> substitution for ...). Don't sweat the details; portability is up
    >> to your compiler(s).

    >
    > And it is execreble dangerous coding in C.


    Whether that's "execreble dangerous" depends on your compiler. If
    malloc has been declared, it's not dangerous, merely superfluous and
    ugly. If malloc hasn't been declared, a good compiler should complain
    with or without the cast.

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Sep 16, 2007
    #17
  18. On 2007-09-16 01:36, Karl Heinze <nomail@invalid> wrote:
    > On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
    ><> wrote:
    >> http://c-faq.com/malloc/mallocnocast.html
    >>

    > Thanx. Though I don't buy in that "argument".
    >
    > Consider:
    >
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > char *p = (char *) malloc(10);
    >
    > return 0;
    > }
    >
    > At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.
    >
    > Same with Pelles C: "Missing prototype for 'malloc'".
    >
    > Same with gcc: "implicit declaration of function 'malloc'".


    Once upon a time most compilers didn't warn about missing prototypes but
    they did warn about conversions from int to a pointer. In these days not
    casting malloc was the most reliable way to catch a missing declaration
    of malloc.

    Today I would advise anybody who's using such a compiler to get a
    better one.

    > So _my_ "A:" is: There's NOTHING wrong with casting malloc's return
    > value. (But don't forget to include <stdlib.h>, man!)


    There is STILL something wrong with casting malloc's return value: It is
    unnecessary and clutters up the code. Also it gets you into the bad
    habit of inserting unnecessary casts which *will* hide subtle errors.

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Sep 16, 2007
    #18
  19. "Peter J. Holzer" <> schrieb im Newsbeitrag
    news:...
    > On 2007-09-16 03:16, CBFalconer <> wrote:
    >> Phlip wrote:
    >>> Wade Ward wrote:
    >>>
    >>>>> Yes, I've done this before...
    >>>
    >>>> I think the common subset of c and c++ is empty, because if you
    >>>> do malloc then yikes and if you don't malloc, well that's not
    >>>> much of a program is it.
    >>>
    >>> Actually I haven't done the Common Subset thing.
    >>>
    >>> But (char*)malloc(..) is well-formed C++ (with appropriate
    >>> substitution for ...). Don't sweat the details; portability is up
    >>> to your compiler(s).

    >>
    >> And it is execreble dangerous coding in C.

    >
    > Whether that's "execreble dangerous" depends on your compiler. If
    > malloc has been declared, it's not dangerous, merely superfluous and
    > ugly. If malloc hasn't been declared, a good compiler should complain
    > with or without the cast.

    a diagnostic is not required by the standared for an implicit declared
    function
    without the cast and in absence of a prototype the compiler has to assume
    int. Assiging an int to a pointer ist a constraint violation (6.5.16.1-1)
    and as such requires a diagnostic (5.1.1.3-1)

    While indeed a good compiler might warn about the missing prototype, even a
    not so good one has to warn about the incompatible types in assignement (if
    not it's a bad and non-conforming one). The latter doesn't happen if there's
    a cast, hence not using the cast is the safer bet.

    Bye, Jojo
     
    Joachim Schmitz, Sep 16, 2007
    #19
  20. "Peter J. Holzer" <> schrieb im Newsbeitrag
    news:...
    > On 2007-09-16 01:36, Karl Heinze <nomail@invalid> wrote:
    >> On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
    >><> wrote:
    >>> http://c-faq.com/malloc/mallocnocast.html
    >>>

    >> Thanx. Though I don't buy in that "argument".
    >>
    >> Consider:
    >>
    >> #include <stdio.h>
    >>
    >> int main(void)
    >> {
    >> char *p = (char *) malloc(10);
    >>
    >> return 0;
    >> }
    >>
    >> At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.
    >>
    >> Same with Pelles C: "Missing prototype for 'malloc'".
    >>
    >> Same with gcc: "implicit declaration of function 'malloc'".

    >
    > Once upon a time most compilers didn't warn about missing prototypes but
    > they did warn about conversions from int to a pointer. In these days not
    > casting malloc was the most reliable way to catch a missing declaration
    > of malloc.

    Because they are required to do diagnose the conversionm and free to do do
    the same with the missing prototype

    Bye, Jojo
     
    Joachim Schmitz, Sep 16, 2007
    #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:
    525
    Rajesh Kumar
    Nov 2, 2004
  2. Francisco Camarero

    VHDL Coding Guidelines

    Francisco Camarero, Jul 8, 2003, in forum: VHDL
    Replies:
    1
    Views:
    2,081
  3. Roger

    Portable Coding Guidelines?

    Roger, Dec 17, 2004, in forum: VHDL
    Replies:
    0
    Views:
    550
    Roger
    Dec 17, 2004
  4. Mike Kruchten

    Are there any guidelines for source control?

    Mike Kruchten, Apr 30, 2004, in forum: ASP .Net
    Replies:
    7
    Views:
    329
    John Saunders
    May 3, 2004
  5. sk
    Replies:
    5
    Views:
    2,257
    Shardul Kulkarni
    Mar 10, 2005
Loading...

Share This Page