468,512 Members | 1,361 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

Help with Extern C

#include <iostream>

using namespace std;

int main()
{

extern "C" int f(int, int);

cout << f(2,3);
cin.get();
}

int f(int x, int y)
{return (x* 234);}

Using Dev C++ with Windows XP, the above code would not compile. The
error messages were: syntax error before string constant and f
undeclared.

This puzzles me somewhat as it seems quite a faithful rendering of the
extern C section of the C++ primer 4th edition.

What am I missing?

It is correct that this use of extern C is completely redundant because
the code has no features that are unique to C or unique to C++.
However, that doesn't seem a likely reason for the compiler to
complain.

The whole reason I got into this extern C business is that I wanted to
use the C facility of suspending type-checking for function parameters
using the (...) notation.

However, I couldn't get this to work. If someone can help me with
this, I would be grateful. C++ primer seems to imply that c++ already
supports this ellipsis notation but I didn't find it straightforward.

Thank you very much for your help.

Paul Epstein

Sep 12 '06 #1
7 4844
pa**********@att.net writes:
>#include <iostream>
>using namespace std;

>int main()
{
extern "C" int f(int, int);
cout << f(2,3);
cin.get();
}
int f(int x, int y)
{return (x* 234);}
>Using Dev C++ with Windows XP, the above code would not compile.
I think that if you put the code for f in a separate file and compile
it with a C compiler, you'll have more luck.
>It is correct that this use of extern C is completely redundant because
the code has no features that are unique to C or unique to C++.
The issue is more to do with name-mangling. See the "C++ calling C"
section of
http://www-h.eng.cam.ac.uk/help/tpl/...languages.html

Sep 12 '06 #2
pa**********@att.net wrote:
#include <iostream>

using namespace std;

int main()
{

extern "C" int f(int, int);

cout << f(2,3);
cin.get();
}

int f(int x, int y)
{return (x* 234);}

Using Dev C++ with Windows XP, the above code would not compile. The
error messages were: syntax error before string constant and f
undeclared.

This puzzles me somewhat as it seems quite a faithful rendering of the
extern C section of the C++ primer 4th edition.

What am I missing?

It is correct that this use of extern C is completely redundant because
the code has no features that are unique to C or unique to C++.
However, that doesn't seem a likely reason for the compiler to
complain.

The whole reason I got into this extern C business is that I wanted to
use the C facility of suspending type-checking for function parameters
using the (...) notation.

However, I couldn't get this to work. If someone can help me with
this, I would be grateful. C++ primer seems to imply that c++ already
supports this ellipsis notation but I didn't find it straightforward.

Thank you very much for your help.

Paul Epstein
Why do you put f inside main definition?
Sep 12 '06 #3

Carlos Martinez wrote:
Why do you put f inside main definition?
Carlos, I don't understand your question at all.

Clearly, my posted code doesn't work.

However, without using extern "C" it works very well.

When you say that I "put" f inside the main definition, what do you
mean by "put"? I was declaring the function f.

Paul Epstein

Sep 12 '06 #4
Carlos Martinez wrote:
Why do you put f inside main definition?
It's perfectly legal to declare function prototypes locally, although
it's less common than simply declaring them at the global scope.

Regards,
Bart.

Sep 12 '06 #5
pa**********@att.net wrote:
#include <iostream>
using namespace std;
int main()
{
extern "C" int f(int, int);
cout << f(2,3);
cin.get();
}

int f(int x, int y)
{return (x* 234);}

Using Dev C++ with Windows XP, the above code would not compile. The
error messages were: syntax error before string constant and f
undeclared.

This puzzles me somewhat as it seems quite a faithful rendering of the
extern C section of the C++ primer 4th edition.

What am I missing?
Write it as:

extern "C"
{
int f(int, int);
}

at the global scope.

Regards,
Bart.

Sep 12 '06 #6
On 12 Sep 2006 03:06:56 -0700, pa**********@att.net wrote in
comp.lang.c++:
#include <iostream>

using namespace std;

int main()
{

extern "C" int f(int, int);

cout << f(2,3);
cin.get();
}

int f(int x, int y)
{return (x* 234);}

Using Dev C++ with Windows XP, the above code would not compile. The
error messages were: syntax error before string constant and f
undeclared.

This puzzles me somewhat as it seems quite a faithful rendering of the
extern C section of the C++ primer 4th edition.

What am I missing?
What you are missing is the fact that your prototype and your function
definition do not match. Your prototype inside main is for a file
named 'f' with C linkage, your definition after main is for a file
named 'f' with C++ linkage, because you did not put extern "C" around
the definition. These are the declarations of two different
overloaded functions with the same name.

C++ allows for a set of overloaded functions to include exactly one
with C linkage, although it can have any number with C++ linkage.

So your code in main() is trying to call a function described by the
declaration in scope at the time, not another overloaded function of
the same name.

This is no different than if you removed the extern "C" from the
declaration inside main, but changed the function definition to:

int f (double x, double y);

The call would still fail, because you are not calling the f() that
you actually defined, but a different overloaded function with the
same name, that you have not supplied.
It is correct that this use of extern C is completely redundant because
the code has no features that are unique to C or unique to C++.
However, that doesn't seem a likely reason for the compiler to
complain.
I am not sure, and I am too lazy to look up, whether C++ actually
allows two overloaded functions to have exactly the same argument list
just because one of them has C linkage. I don't think so, as the call
would be ambiguous, but I might be wrong.
The whole reason I got into this extern C business is that I wanted to
use the C facility of suspending type-checking for function parameters
using the (...) notation.
The ellipsis for functions for variable arguments lists works EXACTLY
the same in C++ as it does in C. The limitation is that you can only
pass POD (Plain Old Data) types as the variable arguments.
However, I couldn't get this to work. If someone can help me with
this, I would be grateful. C++ primer seems to imply that c++ already
supports this ellipsis notation but I didn't find it straightforward.
If what you are really trying to do is to create and call a variadic
function in C++, then post the code you can't get to work for doing
that, and ask for help.
Thank you very much for your help.

Paul Epstein
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Sep 12 '06 #7

Jack Klein wrote:
....
What you are missing is the fact that your prototype and your function
definition do not match. Your prototype inside main is for a file
named 'f' with C linkage, your definition after main is for a file
named 'f' with C++ linkage, because you did not put extern "C" around
the definition. These are the declarations of two different
overloaded functions with the same name.
....

Thanks. So it seems I should have used extern "C" twice and I
understand why. However, I couldn't get this to work. I made various
attempts to write extern "C" during the function definition and always
got a compilation error or linker error.

Could you be a bit more precise as to where to put the 2nd extern "C"
to get it to work (or direct me to a website which explains it.)

Thanks,

Paul Epstein

Sep 12 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Timothy Shih | last post: by
reply views Thread by Benoit Courchesne | last post: by
reply views Thread by Nick Jacobson | last post: by
2 posts views Thread by Nick Jacobson | last post: by
1 post views Thread by llihp | last post: by
9 posts views Thread by Ringo | last post: by
reply views Thread by RLC | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.