linking C with C++

Discussion in 'C++' started by johny smith, May 17, 2004.

  1. johny smith

    johny smith Guest

    Can someone please explain to me why when linking a C with a C++ program
    that there has to be some flag to check to see if it is compiled with C++.

    For example. This is not exactly correct but hopefully gives the idea.

    Thanks in advance.


    #ifdef _cplusplus

    extern c

    {



    }

    #endif
     
    johny smith, May 17, 2004
    #1
    1. Advertising

  2. johny smith

    Gregg Guest

    "johny smith" <> wrote in
    news::

    > Can someone please explain to me why when linking a C with a C++
    > program that there has to be some flag to check to see if it is
    > compiled with C++.


    Unlike C compilers, C++ compilers need, when generating an object file,
    to "decorate" the symbols with type information in order to support
    overloading (using the same symbol for two or more functions with
    different parameter types). Since C does not support overloading like
    this, C compilers do not generate this decoration.

    The extern "C" tells the C++ compiler not to adorn symbol names with type
    information, but insted to store the symbol the way a C compiler would.
    Of course, functions declared this way will not support overloading, and
    must be non-member or static member functions.

    The #ifdef __cplusplus is required because only the C++ compiler
    understands the extern "C" declaration. You would normally see something
    like this:

    #ifdef __cplusplus
    extern "C" {
    #endif

    /* stuff to be used by both C and C++ here */

    #ifdef __cplusplus
    }
    #endif

    Hope this helps.

    Gregg
     
    Gregg, May 17, 2004
    #2
    1. Advertising

  3. johny smith

    Gregg Guest

    Gregg <> wrote in
    news:Xns94EBDF2294363gregginvalidinvalid@207.69.154.203:

    > The #ifdef __cplusplus is required because only the C++ compiler
    > understands the extern "C" declaration. You would normally see
    > something like this:
    >
    > #ifdef __cplusplus
    > extern "C" {
    > #endif
    >
    > /* stuff to be used by both C and C++ here */
    >
    > #ifdef __cplusplus
    > }
    > #endif


    Let me clarify. The #ifdef __cplusplus allows the same header to be
    included by both C and C++ source files. The #ifdef __cplusplus is not
    required if the header is going to be included only by a C++ source file
    and never by a C source file.

    Gregg
     
    Gregg, May 17, 2004
    #3
  4. Gregg wrote:
    >
    > "johny smith" <> wrote in
    > news::
    >
    > > Can someone please explain to me why when linking a C with a C++
    > > program that there has to be some flag to check to see if it is
    > > compiled with C++.

    >
    > Unlike C compilers, C++ compilers need, when generating an object file,
    > to "decorate" the symbols with type information in order to support
    > overloading (using the same symbol for two or more functions with
    > different parameter types). Since C does not support overloading like
    > this, C compilers do not generate this decoration.
    >
    > The extern "C" tells the C++ compiler not to adorn symbol names with type
    > information, but insted to store the symbol the way a C compiler would.
    > Of course, functions declared this way will not support overloading, and
    > must be non-member or static member functions.
    >


    Member functions cannot have C linkage, even if static (the compiler will
    ignore the extern "C" {...} applied to them).

    Interestingly, the standard avoids specifying what a language linkage
    (either C++ or C) must or should entail, leaving it to the implementation.
    So I suppose that instead of C++ name mangling we could have had some other
    mechanism. I also read it to mean that, in principle, C and C++ linkages
    are allowed to use different calling conventions. At any rate, it is
    undefined behaviour to call a function through an expression with a different
    language linkage; e.g., to use a pointer to a static member function where
    a "C" function is expected.
    (I have a vague idea of the real world implications of the last rule, but
    I don't see a reason not to follow it).

    Denis
     
    Denis Remezov, May 17, 2004
    #4
  5. johny smith

    Gregg Guest

    Denis Remezov <> wrote in
    news::

    >
    > Member functions cannot have C linkage, even if static (the compiler
    > will ignore the extern "C" {...} applied to them).
    >


    Yes, that is what the standard says. I'm not sure what I was thinking of
    when I wrote that, but it may have been the idea of using a static member
    function as the target of a callback from code expecting a C function.
    That of course does not involve symbolic linkage, but does involve ABI
    compatibility (stack frame layout, register usage, and other calling
    conventions).

    > Interestingly, the standard avoids specifying what a language linkage
    > (either C++ or C) must or should entail, leaving it to the
    > implementation. So I suppose that instead of C++ name mangling we
    > could have had some other mechanism. I also read it to mean that, in
    > principle, C and C++ linkages are allowed to use different calling
    > conventions. At any rate, it is undefined behaviour to call a
    > function through an expression with a different language linkage;
    > e.g., to use a pointer to a static member function where a "C"
    > function is expected. (I have a vague idea of the real world
    > implications of the last rule, but I don't see a reason not to follow
    > it).


    That is all technically true, but practically speaking, it is name-
    mangling that is the significant difference when mixing C and C++ (at
    least when using compilers from the same vendor).

    Gregg
     
    Gregg, May 18, 2004
    #5
  6. johny smith

    Sergei Guest


    > > Interestingly, the standard avoids specifying what a language linkage
    > > (either C++ or C) must or should entail, leaving it to the
    > > implementation. So I suppose that instead of C++ name mangling we
    > > could have had some other mechanism. I also read it to mean that, in
    > > principle, C and C++ linkages are allowed to use different calling
    > > conventions. At any rate, it is undefined behaviour to call a
    > > function through an expression with a different language linkage;
    > > e.g., to use a pointer to a static member function where a "C"
    > > function is expected. (I have a vague idea of the real world
    > > implications of the last rule, but I don't see a reason not to follow
    > > it).

    >
    > That is all technically true, but practically speaking, it is name-
    > mangling that is the significant difference when mixing C and C++ (at
    > least when using compilers from the same vendor).
    >


    Not sure it is true even in a majority of cases. For instance, in my latest
    project I had to access
    a third party DLL exporting "C" functions from my C++ program using
    GetProcAddress(). The function was resolved
    by name just fine, but when trying to call it I was getting that MS runtime
    ( ESA (sp?)) error about calling convention until I typedef-ed
    the type that I was using to store the pointer to resolved function with
    "extern "C"" . Then it worked.

    Sergei
     
    Sergei, May 18, 2004
    #6
  7. johny smith

    Jerry Coffin Guest

    Gregg <> wrote in message news:<Xns94ED8D8EF9C9gregginvalidinvalid@207.69.154.202>...

    [ ... ]

    > That is all technically true, but practically speaking, it is name-
    > mangling that is the significant difference when mixing C and C++ (at
    > least when using compilers from the same vendor).


    That's not really accurate -- quite a few compilers typically use
    different calling conventions between the two languages. Since C can
    be written without prototypes, C compilers often default to argument
    passing that can withstand differences between the number of arguments
    passed and number of arguments expected by the function.

    In C++, function declarations are required. Since we know the
    arguments in the call match those expected by the function, they can
    use a more efficient calling convention.

    In reality, the name mangling mostly just prevents you from making
    calls that would just crash and burn anyway.
    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, May 18, 2004
    #7
  8. Jerry Coffin wrote:
    > [..] Since C can
    > be written without prototypes, [...]


    Not since 1999 it can't.

    V
     
    Victor Bazarov, May 18, 2004
    #8
    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. Guest

    not linking msvcr70.dll

    Guest, Aug 11, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    964
    Guest
    Aug 11, 2004
  2. tinoosh

    Linking problem in Primetime

    tinoosh, May 6, 2005, in forum: VHDL
    Replies:
    1
    Views:
    630
    topgun
    May 9, 2005
  3. Aditya

    Linking PDF forms with SQL

    Aditya, Aug 12, 2003, in forum: Perl
    Replies:
    0
    Views:
    2,042
    Aditya
    Aug 12, 2003
  4. Sanjay Tibrewal
    Replies:
    0
    Views:
    740
    Sanjay Tibrewal
    Nov 14, 2003
  5. alex
    Replies:
    0
    Views:
    330
Loading...

Share This Page