Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > linking C with C++

Reply
Thread Tools

linking C with C++

 
 
johny smith
Guest
Posts: n/a
 
      05-17-2004
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


 
Reply With Quote
 
 
 
 
Gregg
Guest
Posts: n/a
 
      05-17-2004
"johny smith" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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
 
Reply With Quote
 
 
 
 
Gregg
Guest
Posts: n/a
 
      05-17-2004
Gregg <(E-Mail Removed)> wrote in
news:Xns94EBDF2294363gregginvalidinvalid@207.69.15 4.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
 
Reply With Quote
 
Denis Remezov
Guest
Posts: n/a
 
      05-17-2004
Gregg wrote:
>
> "johny smith" <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
> > 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
 
Reply With Quote
 
Gregg
Guest
Posts: n/a
 
      05-18-2004
Denis Remezov <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

>
> 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
 
Reply With Quote
 
Sergei
Guest
Posts: n/a
 
      05-18-2004

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


 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      05-18-2004
Gregg <(E-Mail Removed)> wrote in message news:<Xns94ED8D8EF9C9gregginvalidinvalid@207.69.15 4.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.
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      05-18-2004
Jerry Coffin wrote:
> [..] Since C can
> be written without prototypes, [...]


Not since 1999 it can't.

V
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Firefox and OE linking opening me Firefox 21 01-12-2005 08:31 PM
peer to peer linking and sharing =?Utf-8?B?QmlsbEM=?= Wireless Networking 2 08-23-2004 08:23 PM
not linking msvcr70.dll ASP .Net 0 08-11-2004 01:07 AM
Directly linking to files such as MSWord willy_gates Firefox 0 05-14-2004 11:12 AM
Linking Firebird / Thunderbird jimm67(nospam) Firefox 0 07-06-2003 01:46 PM



Advertisments