name mangling problem

[Jaco Naude]

Hi,

I am running into a problem where I am trying to import C DLL into a
Visual C++ 2008 application. The functions in the C DLL are obviously
not name mangled (verified using Dependency Walker). When I try to use
any of the functions from the DLL, VC++ mangles these names (or so it
looks like) and complains that it can't link to mangled versions of
the function names. To avoid this I've figured that I need to declare
the functions I would like to use from the DLL as follows:

extern "C"
{
void Py_Initialize(void);
}

Is there any easier way of doing this than to declare all the
functions in the DLL using extern "C"?

Thanks
Jaco

 

[daniel]

Hi,

I am running into a problem where I am trying to import C DLL into a
Visual C++ 2008 application. The functions in the C DLL are obviously
not name mangled (verified using Dependency Walker). When I try to use
any of the functions from the DLL, VC++ mangles these names (or so it
looks like) and complains that it can't link to mangled versions of
the function names. To avoid this I've figured that I need to declare
the functions I would like to use from the DLL as follows:

extern "C"
{
    void Py_Initialize(void);

}

Is there any easier way of doing this than to declare all the
functions in the DLL using extern "C"?

Thanks
Jaco

You could change your C code file extension from .c to .cpp.
But this is not very practical.

Daniel.

 

[Ian Collins]

Hi,

I am running into a problem where I am trying to import C DLL into a
Visual C++ 2008 application. The functions in the C DLL are obviously
not name mangled (verified using Dependency Walker). When I try to use
any of the functions from the DLL, VC++ mangles these names (or so it
looks like) and complains that it can't link to mangled versions of
the function names. To avoid this I've figured that I need to declare
the functions I would like to use from the DLL as follows:

extern "C"
{
void Py_Initialize(void);
}

Is there any easier way of doing this than to declare all the
functions in the DLL using extern "C"?

That's the standard way of informing the C++ compiler functions have C
linkage.

 

[Jaco Naude]

Last time I looked, VC++ did mangle names when compiling C code. It
sticks an underscore on the front.


Well, it mangles them differently from the way they're mangled when
they're compiled as C code.




No, that's what extern "C" is for.

Note that this problem really has nothing to do with the use of DLLs,
except that that's where you happened to notice it. It comes up
whenever you need to link C code with C++ code. You have to tell the
compiler that those things were compiled as C so that it can generate
code with the correct calling convention (which can include more than
just changing how the names are mangled).

--
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Thanks for all the replies. Seems like thats the way to do it. I'll go
with the #define C(X) extern "C" { X; } option for now.

Thanks again.

 

[James Kanze]

#define C(X) extern "C" { X; }

C(void Py_Initialize(void))
C(void Py_Middlize(void))
C(void Py_Terminalize(void))

Assuming typing 'C( )' is easier than typing 'extern "C"{ }'...

That is, quite frankly, horrible. And what happens if you use C
as a name somewhere? Not to mention that the person reading the
code will have no idea what is going on.

With any decent editor, you can set up an abbreviation so that
you just have to type C to get your extern "C", if it is really
typing which is bothering you. (Although seriously, how long
does it take to type `extern "C"?) More generally, however, the
usual solution is to define an extern "C" block for the entire
library, e.g.:

#ifdef __cplusplus
extern "C" {
#endif
void Py_Initialize( void ) ;
void Py_Middlize( void ) ;
// ...
#ifdef __cplusplus
}
#endif

(I don't normally approve of #ifdef, but this is one of those
cases where it is so ubiquious, any other solution would cause
the reader to wonder why it wasn't done this way.)

 

[murat.dogancay]

Hi,

I am running into a problem where I am trying to import C DLL into a
Visual C++ 2008 application. The functions in the C DLL are obviously
not name mangled (verified using Dependency Walker). When I try to use
any of the functions from the DLL, VC++ mangles these names (or so it
looks like) and complains that it can't link to mangled versions of
the function names. To avoid this I've figured that I need to declare
the functions I would like to use from the DLL as follows:

extern "C"
{
    void Py_Initialize(void);

}

Is there any easier way of doing this than to declare all the
functions in the DLL using extern "C"?

Thanks
Jaco

Change "Project options" --> "Configuration Properties" --> C/C++ -->
Advanced --> Compile as
to "Compile as C Code (/TC)" and remove the " Extern "C" "
declarations
thats all folks !
No any other changes required...
__________________
http://www.invenoo.com

 

[ian-news]

Thanks for all the replies. Seems like thats the way to do it. I'll go
with the #define C(X) extern "C" { X; } option for now.

That's the worst possible solution.

Don't forget you can put multiple prototypes inside a single extern
"C" {} block, so you only have to type it once rather than every time
for that horrible macro. That's how system headers are shared between
C and C++.

Ian.

 

[Gennaro Prota]

If I has no compelling reason to do so, I would not use a macro,
and probably not one named C however appropriate that may seem,
to establish extern "C", but that's just me. It implies a non-C too
(or at least an empty C(X), and I think I'd rather prefer to use
a more traditional "co-ed header" file ala the discussion found at
http://www.comeaucomputing.com/techtalk/#externC ).

I'm under the impression that the OP thinks he needs an 'extern "C" {}' for each function. Jaco, of course, you can just write:

extern "C"
{
void Py_Initialize(void);
void function2(void);
void function3(void);
...etc...
}

(without the "...etc..." ). Also, are you sure you don't have the relevant header already?