By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,501 Members | 1,678 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,501 IT Pros & Developers. It's quick & easy.

extern "C" directive and calling conventions

P: n/a
Hi everyone, (Very Sorry, if this is the wrong group in which I am
posting this query).

Code snippet:

//C library
typedef int (*PFunc)(int* aArg);

void call_c_foo(PFunc aPtrtoFunc)
{
int* theArg;
//Assume theArg pointer is valid hereafter
//Do something...and then...call
PFunc(theArg);
//some more stuff
}

================================

//C++ Code using C library

class CPP
{
public:
static int Ditto(int* aInt);
void InMemberFunction()
{
call_c_foo(Ditto);
}
};

=================================

On URL:
http://www.parashift.com/c++-faq-lit....html#faq-33.2
{
although it probably works on most compilers, it actually would have to
be an extern "C" non-member function to be correct, since "C linkage"
doesn't only cover things like name mangling, but also calling
conventions, which might be different between C and C++.
}

3 QUESTIONS:

1) What does Standard C++ say on this issue? Does the static fucntion
in class CPP is compiled by _most_ of compilers the way it would have
been compiled if it was given extern "C" linkage? In other words, do
_most_ of compilers treat both - static fucntion directive and extern
"C" directive - to be same? Also, why does C++ not allow to declare
linkage of a class to be partly as C and partly as C++? What are the
difficulties in doing this on part of a compiler writer?

2) When I say that a given piece of code (in C++) has "C" linkage, does
it mean that C++ compiler will "supress" its calling conventions as
well when setting up a C call within C++ code while compiling? More
curiously, what all things does a C++ compiler do when it encounters
extern "C" directive while compiling a C++ code?

3) I would have assumed that calling conventions for both extern "C"
linked calls and C++ calls would be same _if_ both the C code (in our
case - the above C library) and C++ code is compiled by _same_
compiler. Is my understanding true?

Thank you very much for the answers in advance,
-Viren

Aug 25 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Ian
RainBow wrote:

3 QUESTIONS:

1) What does Standard C++ say on this issue? Does the static fucntion
in class CPP is compiled by _most_ of compilers the way it would have
been compiled if it was given extern "C" linkage? In other words, do
_most_ of compilers treat both - static fucntion directive and extern
"C" directive - to be same? Also, why does C++ not allow to declare
linkage of a class to be partly as C and partly as C++? What are the
difficulties in doing this on part of a compiler writer?
No, it will be a C++ function and have its name mangled. The standard
says nothing about calling conventions.
2) When I say that a given piece of code (in C++) has "C" linkage, does
it mean that C++ compiler will "supress" its calling conventions as
well when setting up a C call within C++ code while compiling? More
curiously, what all things does a C++ compiler do when it encounters
extern "C" directive while compiling a C++ code?
In practice, it turns of name mangling so the function name will be
exported "as is".
3) I would have assumed that calling conventions for both extern "C"
linked calls and C++ calls would be same _if_ both the C code (in our
case - the above C library) and C++ code is compiled by _same_
compiler. Is my understanding true?

For every implementation I have seen, yes. It wouldn't be of any use
otherwise. In practice, it will also work with any other C compiler on
the same platform.

Ian
Aug 25 '05 #2

P: n/a
> 3) I would have assumed that calling conventions for both extern "C"
linked calls and C++ calls would be same _if_ both the C code (in our
case - the above C library) and C++ code is compiled by _same_
compiler. Is my understanding true?

For every implementation I have seen, yes. It wouldn't be of any use
otherwise. In practice, it will also work with any other C compiler on

the same platform.

I am actually thinking now as to how does a C++ compiler treat a class
member function versus a static member function. E.g VC++ might be
treating a class member function differently when setting up a call
(they use "this calling convention") versus a static member function
(do not use "this" calling convention here). If this is true, then VC++
is actually using 2 calling conventions for same compilation unit :
this and normal __std for static functions (that is also used for C
calls).

I am sure my understanding is completely screwed up here, but I am very
curious to learn more on this topic. I really need to write some
"portable" code and lack of this understanding is giving me restless
nights.

-Viren

Aug 25 '05 #3

P: n/a
Ian
RainBow wrote:
3) I would have assumed that calling conventions for both extern "C"
linked calls and C++ calls would be same _if_ both the C code (in our
case - the above C library) and C++ code is compiled by _same_
compiler. Is my understanding true?
For every implementation I have seen, yes. It wouldn't be of any use
otherwise. In practice, it will also work with any other C compiler on

the same platform.

I am actually thinking now as to how does a C++ compiler treat a class
member function versus a static member function. E.g VC++ might be
treating a class member function differently when setting up a call
(they use "this calling convention") versus a static member function
(do not use "this" calling convention here). If this is true, then VC++
is actually using 2 calling conventions for same compilation unit :
this and normal __std for static functions (that is also used for C
calls).

Don't get too caught up in this, how the compiler generates C++ member
and static member calls is its business, don't worry about it. No two
C++ compilers generate code that can be used with another.

That's one of the reasons to use extern "C", to get a portable interface
between say VC++ and gcc.
I am sure my understanding is completely screwed up here, but I am very
curious to learn more on this topic. I really need to write some
"portable" code and lack of this understanding is giving me restless
nights.

If you want to see what your compiler does under the hood, find the
option that emits an assembler file and study that.

Ian
Aug 25 '05 #4

P: n/a
Ian wrote:
RainBow wrote:

3 QUESTIONS:

1) What does Standard C++ say on this issue? Does the static fucntion
in class CPP is compiled by _most_ of compilers the way it would have
been compiled if it was given extern "C" linkage? In other words, do
_most_ of compilers treat both - static fucntion directive and extern
"C" directive - to be same?
Most seem to do, yes, but that is an error. They are not supposed to.
Also, why does C++ not allow to declare linkage of a class to be partly
as C and partly as C++? What are the difficulties in doing this on part
of a compiler writer?

No, it will be a C++ function and have its name mangled. The standard
says nothing about calling conventions.


That's not true. The C++ standard says that calling conventions can be part
of "linkage" and thus, an extern "C" function is not guaranteed to be
callable through a pointer to a function that is not.

Aug 25 '05 #5

P: n/a
Ian wrote:
In practice, it turns of name mangling so the function name will be
exported "as is".


In practice extern "C" applies the same mangling as the targetted C
compiler. Often that means adding an underscore at the beginning of the
name; sometimes it means using the same name; sometimes it means adding
an underscore at the end. Or it could mean something completely different.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Aug 25 '05 #6

P: n/a
RainBow wrote:
3) I would have assumed that calling conventions for both extern "C"
linked calls and C++ calls would be same if both the C code (in our
case - the above C library) and C++ code is compiled by same
compiler. Is my understanding true?

For every implementation I have seen, yes. It wouldn't be of any use
otherwise. In practice, it will also work with any other C compiler
on

It looks to me like you want to quote while using Google, but don't
know how, so you did a cut and paste from the previous message.

To get proper quoting and attributions from Google, click "show
options" and use the Reply shown in the expanded header.


Brian
Aug 25 '05 #7

P: n/a
If it is allowed/legal, can you please dump the relevant paragraph from
Standards here so that I get a chance to read exactly what does the
standard say? I will need to explain my design during the review, so
this quote from Standards will come handy. Sorry, I /my company does
not have a copy of current C++ standards.

Thanks and regards.

Aug 25 '05 #8

P: n/a
:-) I know I should be doing that but I am really running out of time
to do this R&D. Sorry.

Aug 25 '05 #9

P: n/a
Ian
Rolf Magnus wrote:
Ian wrote:

RainBow wrote:
3 QUESTIONS:

1) What does Standard C++ say on this issue? Does the static fucntion
in class CPP is compiled by _most_ of compilers the way it would have
been compiled if it was given extern "C" linkage? In other words, do
_most_ of compilers treat both - static fucntion directive and extern
"C" directive - to be same?

Most seem to do, yes, but that is an error. They are not supposed to.

Also, why does C++ not allow to declare linkage of a class to be partly
as C and partly as C++? What are the difficulties in doing this on part
of a compiler writer?


No, it will be a C++ function and have its name mangled. The standard
says nothing about calling conventions.

That's not true. The C++ standard says that calling conventions can be part
of "linkage" and thus, an extern "C" function is not guaranteed to be
callable through a pointer to a function that is not.

Agreed, I should have said "The standard says nothing about calling
convention implementation".

Ian
Aug 25 '05 #10

P: n/a
RainBow wrote:
:-) I know I should be doing that but I am really running out of time
to do this R&D. Sorry.

Others don't seem to be bothered by this lack of quoting, but it's
bugging me. To get proper quotes and attributions from Google, click
"show options" and use the Reply shown in the expanded header.


Brian
Aug 25 '05 #11

P: n/a
Ian
RainBow wrote:
If it is allowed/legal, can you please dump the relevant paragraph from
Standards here so that I get a chance to read exactly what does the
standard say? I will need to explain my design during the review, so
this quote from Standards will come handy. Sorry, I /my company does
not have a copy of current C++ standards.

Is what legal? If you want decent replies, please quote correctly.

Have a read of section 7.4, please don't ask people to quote copyright
material, it only costs $18 to download.

Ian
Aug 25 '05 #12

P: n/a
I am sorry - I did not mean to offend anyone. By legal, I meant if it
is permitted by this group or by your company. And I am sorry again, I
was not knowing that the cost is $18 - my guess was it must be
something in range of $500 soemthing.

Lastly, please try to understand that not everyone who visits/posts in
this group has English as their first language. So, it is very much
possible that people may just use some wrong word in wrong context -
but believe me, they dont mean what it actually looks like to an
English expert.

In apology again.

Aug 25 '05 #13

P: n/a
Ian
RainBow wrote:
I am sorry - I did not mean to offend anyone. By legal, I meant if it
is permitted by this group or by your company. And I am sorry again, I
was not knowing that the cost is $18 - my guess was it must be
something in range of $500 soemthing.

Lastly, please try to understand that not everyone who visits/posts in
this group has English as their first language. So, it is very much
possible that people may just use some wrong word in wrong context -
but believe me, they dont mean what it actually looks like to an
English expert.

In apology again.

No need, but please quote when responding, that's why I wasn't sure if
you were referring to something I had said being legal C++!

Ian
Aug 25 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.