On 8/24/2010 4:50 AM, Stanisław Findeisen wrote:
> Hi!
>
> I have some questions regarding calling C functions from C++ and vice
> versa. This is based on some points I've found on parashift.com:
>
> ======================================================================
> If you are including a C header file that isn't provided by the system,
> you may need to wrap the #include line in an extern "C" { /*...*/ }
> construct. This tells the C++ compiler that the functions declared in
> the header file are C functions.
>
> http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html#faq-32.3
> ======================================================================
>
> 1. What if I don't wrap them? Is it possible to have runtime errors
> because of that? I understand linker errors are possible.
This is just addressing name mangling issues. Look up "name mangling"
on Google.
That is an interesting recommendation by Parashift. I read that as:
extern "C" {
#include "somefile.h"
}
I don't think I've ever seen that approach before.
This section could use some better wording and the comments (/* ... */)
seem wrong.
> 2. When do you think this wrapping is not needed, i.e. what do you think
> "provided by the system" was meant to mean? Parashift.com author gives
> <cstdio> as an example, but what about POSIX headers like<pthread.h> or
> <sys/socket.h>? Do you need to wrap them in extern "C" in portable code?
Those are provided by the system. The author is referring to
third-party code not supplied by the vendor directly. I suppose there
is a fine line here as to what qualifies. Again, the section could use
some work.
> ======================================================================
> [32.6] How can I create a C++ function f(int,char,float) that is
> callable by my C code?
>
> The C++ compiler must know that f(int,char,float) is to be called by a C
> compiler using the extern "C" construct [...]
>
> http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html#faq-32.6
> ======================================================================
>
> ======================================================================
> [...] static member functions do not require an actual object to be
> invoked, so pointers-to-static-member-functions are usually
> type-compatible with regular pointers-to-functions. However, 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++.
>
> http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.2
> ======================================================================
>
> 3. Is it possible to have runtime errors if you don't use extern "C" in
> this case? I think YES?
Only if name mangling gets screwed up really badly somehow. The linker
is usually pretty good about preventing such things. The runtime error
would almost always be the inability to load a module (.dll/.so) because
one or more of the exports won't resolve dynamically and then the whole
program would fail to load as a result. That is, the OS won't load the
program in the first place due to dependency issues. However, as I
said, the linker is pretty good about preventing such problems.
I've never had compilation problems like that where the same compiler
suite is used for all the components being built.
> 4. What effect does extern "C" have on C++ function in this case? It's
> about generating machine code of the function itself, right? No wrapper?
> So when you call this C++ function from within C++ code (from the same
> or another translation unit), the C calling convention should be used?
Not sure what you are asking here. I think you are just confused at
this point. I know the feeling.
> I am doing some initialization using pthread_once, and apparently it
> works here on Debian GNU/Linux with g++ when I pass a private static
> member function pointer to pthread_once (no extern "C", either). :-)
POSIX libraries will generally build against a C++ environment without
issues because the authors have hammered out those libraries for
numerous environments. You don't have to worry about extern "C" here.
> I only care about POSIX and GNU/Linux.
I care about whatever gets the job done. Linux is fine for some things.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
http://barebonescms.com/
