Re: Differences between C and C++

Discussion in 'C Programming' started by jameskuyper, Feb 8, 2011.

  1. jameskuyper

    jameskuyper Guest

    On Tuesday, February 8, 2011 3:07:18 PM UTC-5, Lew Pitcher wrote:
    > On February 9, 2011 14:59, in comp.lang.c, wrote:
    >
    > >
    > > This may be a FAQ, but I did some searching and did not find an answer
    > > that satisfied me.
    > >
    > > I seem to remember people on this group claiming strongly that despite
    > > their similarities, C and C++ are two different languages, and are
    > > best treated as such.

    >
    > Yes, both assertions are true.
    > C and C++ each have their own language definition, individually standardized
    > by both national and international standards bodies. It is not difficult to
    > locate copies of these standards documents, and a comparison of them will
    > show that C and C++ are two different languages, similar only in a small
    > subset.


    That subset could be called "small" by comparison with C++, since C++ is such a large language. However, that subset has almost precisely the same set of features as C itself. Most of the C features missing from that subset are obsolescent features that most modern C programmers make little or no use of, such as non-prototype functions, or recent C99 additions such as VLAs that have not yet gained wide popularity.

    Most C programs can, with minor re-writes, be converted into code which will compile with either language, with exactly the same meaning in both languages. It's relatively easy to deliberately write code for which this is not true; but such code is usually clearly contrived. It's substantially harder to find code "in the wild", which was not deliberately written for the purpose of showing up the incompatibilities, which poses any serious problem for such a conversion.

    > > Can anyone point me to a summary of the differences between these two
    > > languages,

    >
    > While I don't consider Wikipedia the best source of information, their web
    > page on the subject /does/ have a fair amount of accurate information:
    > http://en.wikipedia.org/wiki/Compatibility_of_C_and_C++



    Annex C of the C++ standard highlights most of the cases syntactically valid C and C++ code has different meanings in both languages. The number of ways in which this can happen is large, but most of them are obscure cases that don't come up very often in modern well-written C code.

    > > and also to information about the possible consequences of e.g. compiling
    > > one language in a compiler intended for the other?
    > > (Obviously, much of C++ will not compile at
    > > all in a C compiler. That is not the interesting part.)

    >
    > AFAIK, the consequences of using the wrong compiler are not defined by
    > either standard.


    Many of the cases listed in Annex C of the C++ standard are constraint violations in one of the two languages - a diagnostic is required. Most of the other cases involve undefined behavior in one of the two languages. There's only a few cases where the behavior is defined in both languages, and different. The most prominent such difference is the type of character constants. The others mostly involve the rules for name spaces (not to be confused with C++ namespaces, which is a different concept).
    jameskuyper, Feb 8, 2011
    #1
    1. Advertising

  2. jameskuyper

    Jorgen Grahn Guest

    On Tue, 2011-02-08, jameskuyper wrote:
    ....

    I wanted to respond to your posting, but it's too broken -- by some
    new Google Groups posting system, I gather. It has caused problems in
    many newsgroups.

    Specifically, your lines are /way/ too long, and you've broken
    threading (the References: header is missing).

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Feb 8, 2011
    #2
    1. Advertising

  3. In article <>,
    jameskuyper <> wrote:
    >
    >That subset could be called "small" by comparison with C++, since C++ is such a large
    >language. However, that subset has almost precisely the same set of features as C
    >itself.


    Agreed. The only speedbumps I've ever encountered is that "class" is
    a reserved word under C++, which can break some code in C that used it
    as a variable name, and that when including C headers in C++ code, those
    headers need the 'extern "C" { ... }' construct.

    I know that there are more differences, but those are the only ones
    I've ever actually had to deal with.

    --
    -Ed Falk,
    http://thespamdiaries.blogspot.com/
    Edward A. Falk, Feb 9, 2011
    #3
  4. jameskuyper

    Nobody Guest

    On Wed, 09 Feb 2011 22:16:16 +0000, Edward A. Falk wrote:

    >>That subset could be called "small" by comparison with C++, since C++ is
    >>such a large language. However, that subset has almost precisely the
    >>same set of features as C itself.

    >
    > Agreed. The only speedbumps I've ever encountered is that "class" is a
    > reserved word under C++, which can break some code in C that used it as
    > a variable name, and that when including C headers in C++ code, those
    > headers need the 'extern "C" { ... }' construct.
    >
    > I know that there are more differences, but those are the only ones I've
    > ever actually had to deal with.


    I used to frequently get bitten by the implicit typedef:

    struct item {...};

    struct item item;

    Mostly because the "description" of the type is the obvious name for the
    structure tag, and when a function deals with a single instance of the
    structure, it's frequently the obvious name for the variable.

    The fact that more people don't seem to get bitten by this seems to be
    due to people either not knowing that structure tags live in a distinct
    namespace, or some weird superstition that it might not be "distinct
    enough".

    C++ basically turned the superstition into a reality, i.e. they're only
    distinct until you want to convert the code to C++.
    Nobody, Feb 10, 2011
    #4
  5. jameskuyper

    Ian Collins Guest

    On 02/10/11 02:36 PM, Nobody wrote:
    > On Wed, 09 Feb 2011 22:16:16 +0000, Edward A. Falk wrote:
    >
    >>> That subset could be called "small" by comparison with C++, since C++ is
    >>> such a large language. However, that subset has almost precisely the
    >>> same set of features as C itself.

    >>
    >> Agreed. The only speedbumps I've ever encountered is that "class" is a
    >> reserved word under C++, which can break some code in C that used it as
    >> a variable name, and that when including C headers in C++ code, those
    >> headers need the 'extern "C" { ... }' construct.
    >>
    >> I know that there are more differences, but those are the only ones I've
    >> ever actually had to deal with.

    >
    > I used to frequently get bitten by the implicit typedef:
    >
    > struct item {...};
    >
    > struct item item;
    >
    > Mostly because the "description" of the type is the obvious name for the
    > structure tag, and when a function deals with a single instance of the
    > structure, it's frequently the obvious name for the variable.
    >
    > The fact that more people don't seem to get bitten by this seems to be
    > due to people either not knowing that structure tags live in a distinct
    > namespace, or some weird superstition that it might not be "distinct
    > enough".
    >
    > C++ basically turned the superstition into a reality, i.e. they're only
    > distinct until you want to convert the code to C++.


    I don't see your problem.

    The C++ code I'm working on the moment contains quite a few instances of

    struct stat stat;

    --
    Ian Collins
    Ian Collins, Feb 10, 2011
    #5
  6. On Feb 9, 8:49 pm, Ian Collins <> wrote:
    > On 02/10/11 02:36 PM, Nobody wrote:
    >
    >
    >
    > > On Wed, 09 Feb 2011 22:16:16 +0000, Edward A. Falk wrote:

    >
    > >>> That subset could be called "small" by comparison with C++, since C++ is
    > >>> such a large language. However, that subset has almost precisely the
    > >>> same set of features as C itself.

    >
    > >> Agreed.  The only speedbumps I've ever encountered is that "class" is a
    > >> reserved word under C++, which can break some code in C that used it as
    > >> a variable name, and that when including C headers in C++ code, those
    > >> headers need the 'extern "C" { ... }' construct.

    >
    > >> I know that there are more differences, but those are the only ones I've
    > >> ever actually had to deal with.

    >
    > > I used to frequently get bitten by the implicit typedef:

    >
    > >    struct item {...};

    >
    > >    struct item item;

    >
    > > Mostly because the "description" of the type is the obvious name for the
    > > structure tag, and when a function deals with a single instance of the
    > > structure, it's frequently the obvious name for the variable.

    >
    > > The fact that more people don't seem to get bitten by this seems to be
    > > due to people either not knowing that structure tags live in a distinct
    > > namespace, or some weird superstition that it might not be "distinct
    > > enough".

    >
    > > C++ basically turned the superstition into a reality, i.e. they're only
    > > distinct until you want to convert the code to C++.

    >
    > I don't see your problem.
    >
    > The C++ code I'm working on the moment contains quite a few instances of
    >
    > struct stat stat;
    >
    > --
    > Ian Collins


    He is talking about this:

    temp(919)$ cat foo.c
    int main(void)
    {
    typedef struct stat {
    int foo;
    } stat;

    struct stat bar;

    return 0;
    }
    temp(920)$ gcc -o foo -Wall foo.c
    foo.c: In function 'main':
    foo.c:7: warning: unused variable 'bar'
    temp(921)$ cat foo.cpp
    int main(void)
    {
    typedef struct stat {
    int foo;
    } stat;

    struct stat bar;

    return 0;
    }
    temp(922)$ g++ -Wall -o foo foo.cpp
    foo.cpp: In function 'int main()':
    foo.cpp:7: error: using typedef-name 'stat' after 'struct'
    foo.cpp:5: error: 'stat' has a previous declaration here
    foo.cpp:7: error: invalid type in declaration before ';' token
    foo.cpp:7: warning: unused variable 'bar'

    -David
    David Resnick, Feb 10, 2011
    #6
  7. jameskuyper

    James Kuyper Guest

    On 02/09/2011 08:49 PM, Ian Collins wrote:
    > On 02/10/11 02:36 PM, Nobody wrote:
    >> On Wed, 09 Feb 2011 22:16:16 +0000, Edward A. Falk wrote:
    >>
    >>>> That subset could be called "small" by comparison with C++, since
    >>>> C++ is
    >>>> such a large language. However, that subset has almost precisely the
    >>>> same set of features as C itself.
    >>>
    >>> Agreed. The only speedbumps I've ever encountered is that "class" is a
    >>> reserved word under C++, which can break some code in C that used it as
    >>> a variable name, and that when including C headers in C++ code, those
    >>> headers need the 'extern "C" { ... }' construct.
    >>>
    >>> I know that there are more differences, but those are the only ones I've
    >>> ever actually had to deal with.

    >>
    >> I used to frequently get bitten by the implicit typedef:
    >>
    >> struct item {...};
    >>
    >> struct item item;
    >>
    >> Mostly because the "description" of the type is the obvious name for the
    >> structure tag, and when a function deals with a single instance of the
    >> structure, it's frequently the obvious name for the variable.
    >>
    >> The fact that more people don't seem to get bitten by this seems to be
    >> due to people either not knowing that structure tags live in a distinct
    >> namespace, or some weird superstition that it might not be "distinct
    >> enough".
    >>
    >> C++ basically turned the superstition into a reality, i.e. they're only
    >> distinct until you want to convert the code to C++.

    >
    > I don't see your problem.
    >
    > The C++ code I'm working on the moment contains quite a few instances of
    >
    > struct stat stat;


    It's a matter of scope. Your use of that construct was probably in a
    context similar to this, which is permitted in either language:

    struct stat { int i;}
    void func1()
    {
    struct stat stat;
    // other stuff
    }

    This, on the other hand, is a constraint violation in C++, but not in C:
    void func2()
    {
    struct stat { int i;}
    struct stat stat;
    ...
    }

    In both languages, it's a constraint violation to give different meaning
    to the same identifier in the same scope and name space (not to be
    confused with C++ namespaces, which are a different concept). The
    difference is that in C, since struct, union, and enumeration tags can
    never be used without the corresponding keyword, they occupy a different
    name space than object identifiers. In C++, on the other hand, 'stat'
    can be used by itself to refer to the struct type, and struct tags
    therefore share the same name space with object identifiers.
    --
    James Kuyper
    James Kuyper, Feb 10, 2011
    #7
  8. jameskuyper

    BGB Guest

    On 2/9/2011 6:48 PM, William Ahern wrote:
    > Edward A. Falk<> wrote:
    >> In article<>,
    >> jameskuyper<> wrote:
    >>>
    >>> That subset could be called "small" by comparison with C++, since C++ is such a large
    >>> language. However, that subset has almost precisely the same set of features as C
    >>> itself.

    >
    >> Agreed. The only speedbumps I've ever encountered is that "class" is
    >> a reserved word under C++, which can break some code in C that used it
    >> as a variable name, and that when including C headers in C++ code, those
    >> headers need the 'extern "C" { ... }' construct.

    >
    > Which `C' do you use regularly? C90 may share more in common with C++, but
    > C99 introduced a slew of new features not available in C++, like compound
    > literals and designated initializers. None of the C++ implementations I've
    > used even support the latter as an extension, and Apple's GCC 4.3.3 at least
    > supports the former with some quirks (`sizeof (struct foo){ 0 }' is rejected
    > while `sizeof ((struct foo){ 0 })' is accepted; clang++ 2.8 accepts both).
    > C99 also introduced variadiac macros, but most C++ implementations seem to
    > provide that as an extension.
    >
    > Porting C90 code to C++ can be relatively easy; code making extensive use of
    > C99 features can be a headache to port and best avoided as a target of
    > porting to C++, IMO.
    >


    using lots of C99 features also makes it a pain to port to MSVC as well
    (since for those of us who use MSVC as a major compiler, C99 support is
    slow to arrive).

    for example, it was not until VS2010 that MS decided to add 'stdint.h', ...


    but, anyways, it is not difficult to write code which works in both
    languages, even if it does step on a few peoples' ideas about what code
    'should' look like:
    using extra pointer casts (such as when using malloc);
    typically using "()" rather than "(void)";
    ....


    side-note / tangent:

    typically, the C I use is further a subset, as I use a few of my own
    code-processing tools which are not exactly smart, and so a little
    compromise is made to avoid confusing them.

    I was also considering a C variant (or C-like language) where some of
    these restrictions would be imposed in the default case, mostly for sake
    of a few other features:
    ability to parse without knowing the visible typedefs; ...

    in addition to a few related to semantic issues:
    any used macros themselves must form a syntactically valid statement or
    expression, and macros may not be used in a way which would alter
    program structure;
    #ifdef/#endif would be required to obey block-structuring rules;
    ....

    however, a more standard C will be kept around as well, leaving this
    variant mostly for "special case" use, mostly involving using C as a
    scripting language and similar, as standard C has a few issues which
    make it ill-suited for application scripting or use with "eval()"...
    BGB, Feb 10, 2011
    #8
  9. On Feb 8, 8:42 pm, jameskuyper <> wrote:
    > On Tuesday, February 8, 2011 3:07:18 PM UTC-5, Lew Pitcher wrote:
    > > On February 9, 2011 14:59, in comp.lang.c, wrote:

    >
    > > > This may be a FAQ, but I did some searching and did not find an answer
    > > > that satisfied me.

    >
    > > > I seem to remember people on this group claiming strongly that despite
    > > > their similarities, C and C++ are two different languages, and are
    > > > best treated as such.

    >
    > > Yes, both assertions are true.
    > > C and C++ each have their own language definition, individually standardized
    > > by both national and international standards bodies. It is not difficult to
    > > locate copies of these standards documents, and a comparison of them will
    > > show that C and C++ are two different languages, similar only in a small
    > > subset.

    >
    > That subset could be called "small" by comparison with C++, since C++ is such a large language. However, that subset has almost precisely the same set of features as C itself. Most of the C features missing from that subset are obsolescent features that most modern C programmers make little or no use of, such as non-prototype functions, or recent C99 additions such as VLAs that have not yet gained wide popularity.
    >
    > Most C programs can, with minor re-writes, be converted into code which will compile with either language, with exactly the same meaning in both languages. It's relatively easy to deliberately write code for which this is not true; but such code is usually clearly contrived. It's substantially harder to find code "in the wild", which was not deliberately written for the purpose of showing up the incompatibilities, which poses any serious problem for such a conversion.
    >
    > > > Can anyone point me to a summary of the differences between these two
    > > > languages,

    >
    > > While I don't consider Wikipedia the best source of information, their web
    > > page on the subject /does/ have a fair amount of accurate information:
    > >http://en.wikipedia.org/wiki/Compatibility_of_C_and_C++

    >
    > Annex C of the C++ standard highlights most of the cases syntactically valid C and C++ code has different meanings in both languages. The number of ways in which this can happen is large, but most of them are obscure cases that don't come up very often in modern well-written C code.
    >
    > > > and also to information about the possible consequences of e.g. compiling
    > > > one language in a compiler intended for the other?
    > > > (Obviously, much of C++ will not compile at
    > > > all in a C compiler.  That is not the interesting part.)

    >
    > > AFAIK, the consequences of using the wrong compiler are not defined by
    > > either standard.

    >
    > Many of the cases listed in Annex C of the C++ standard are constraint violations in one of the two languages - a diagnostic is required. Most of the other cases involve undefined behavior in one of the two languages. There's only a few cases where the behavior is defined in both languages, and different. The most prominent such difference is the type of character constants.  The others mostly involve the rules for name spaces (not to be confused with C++ namespaces, which is a different concept).


    <james finished here>

    thanks for that post. It echoes my experience writing C that is
    compilable (and has the same semantice) by a C++ isn't hard. I find I
    have to cast a few void*'s and that's about it.
    Nick Keighley, Feb 19, 2011
    #9
    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. Rick
    Replies:
    0
    Views:
    952
  2. Thomas Fritsch
    Replies:
    2
    Views:
    1,002
    Andrey Kuznetsov
    Jul 27, 2006
  3. Home_Job_opportunity
    Replies:
    0
    Views:
    494
    Home_Job_opportunity
    Jan 8, 2009
  4. Home_Job_opportunity
    Replies:
    0
    Views:
    578
    Home_Job_opportunity
    Jan 14, 2009
  5. Kevin Watkins
    Replies:
    2
    Views:
    175
    Kevin Watkins
    Apr 8, 2004
Loading...

Share This Page