How to Avoid Name Mangling

How can i avoid name mangling?

You can't. It's built into compilers to allow you overloading functions and to have functions with the same name in different classes and such stuff. But you can write functions that are mangled like C functions. Those can be called from C code. But those can't be overloaded and can't be called by "normal" C++ function pointers:

extern "C" void foo() {

}

The above function will be mangled like C functions for your compiler. That may include no change at all to the name, or some changes like a leading "_" in front of it or so.

Can't prevent name mangling

Changing calling convention to cdecl worked for me. The extern "C" solution won't of much help to me as in my case the problem was with name mangling while compiling .C files where as if I understand it correctly the extern "C" solution is for suppressing name mangling when compiling cpp files.

Why prevent Name-mangling C files

c++ compiler may not do name mangling on .c files, but it definitely would mangle those included by .cpp files, so in header files it is needed
you can simply use extern "C"{ file content here }, this can be easily done in many tools.

I write a cmd script (.bat) for you

WARNING : this would overwrite existing files, make a backup!

@ECHO OFF
for /R %%f in (*.c,*.h) do (
   @echo extern "C" { > temp
   @echo. >> temp
   @type %%f >> temp
   @echo. >> temp   
   @echo } >> temp
   @type temp > %%f
   @echo processed %%f
)

How to remove mangling in C++

vector is C++ type and so cannot be directly given under extern "C". Give the function inside a class and export the class as C Type.

extern "C"
{
    class __declspec(dllexport) ClassToExport
    {
        vector<TestClass> GetInfoList();
    };
}

Now use this class object to axcess the function.

How do I stop name-mangling of my DLL's exported function?

Small correction - for success resolving name by clinet

extern "C"

must be as on export side as on import.

extern "C" will reduce name of proc to: "_GetName".

More over you can force any name with help of section EXPORTS in .def file

How do you avoid name mangling of C++ procedures?

You need an extern "C" { } block around your definitions to avoid the C++ name mangling.

Is there a way to suppress c++ name mangling?

"bradtgmurray" is right, but for Visual C++ compilers, you need to explicitly export your function anyway. But using a .DEF file as proposed by "Serge - appTranslator" is the wrong way to do it.

What is the universal way to export symbols on Visual C++ ?

Using the declspec(dllexport/dllimport) instruction, which works for both C and C++ code, decorated or not (whereas, the .DEF is limited to C unless you want to decorate your code by hand).

So, the right way to export undecorated functions in Visual C++ is combining the export "C" idiom, as answered by "bradtgmurray", and the dllimport/dllexport keyword.

An example ?

As an example, I created on Visual C++ an empty DLL project, and wrote two functions, one dubbed CPP because it was decorated, and the other C because it wasn't. The code is:

// Exported header
#ifdef MY_DLL_EXPORTS
#define MY_DLL_API __declspec(dllexport)
#else
#define MY_DLL_API __declspec(dllimport)
#endif

// Decorated function export : ?myCppFunction@@YAHF@Z
MY_DLL_API int myCppFunction(short v) ;

// Undecorated function export : myCFunction
extern "C"
{
MY_DLL_API int myCFunction(short v) ;
} ;

I guess you already know, but for completeness' sake, the MY_DLL_API macro is to be defined in the DLL makefile (i.e. the VCPROJ), but not by DLL users.

The C++ code is easy to write, but for completeness' sake, I'll write it below:

// Decorated function code
MY_DLL_API int myCppFunction(short v)
{
   return 42 * v ;
}

extern "C"
{

// Undecorated function code
MY_DLL_API int myCFunction(short v)
{
   return 42 * v ;
}

} ;

how to stop name mangling in Qt class?

I'm going to hazard a guess this might be failing because of this construct:

extern "C"
{
  class I_AM_A_CPLUSPLUS_CONCEPT {};
}

Anyhow, this is solvable, but requires a little rethink. To expose the class to C, you will have to jump through a couple of hoops here.

   // the C++
   class MyClass : public QObject
   {
       Q_OBJECT

   public:
       void SomeFunction(int Parameter);
   };

   extern "C" MyClass* MyClass_new() {
       return new MyClass;
   }

   extern "C" void MyClass_delete(MyClass* c) {
       delete c;
   }

   extern "C" void MyClass_SomeFunction(MyClass* c, int p) {
       c->SomeFunction(p);
   }

'MyClass' will be mangled into a C++ name, and there isn't really any way to expose 'SomeFunction' as a member of MyClass, without using name mangling.

C-Name mangling in the above example will simply expose:

MyClass_new, MyClass_delete, and MyClass_SomeFunction as the symbol names. (i.e. devoid of the function argument types, return type, calling convention, owning class, etc... which is what C++ name mangling will add in).

Just treat MyClass as an opaque pointer, and C code should be happy enough with that. Short of resorting to pybind/boost::python (which clearly don't really work with DLL's cleanly!!), there aren't really any other nice ways to bind in a C++ object to c code.

How to prevent name mangling of javascript functions in django-pipeline

Are you sure that search() is a global function? To make sure you can assign it to the window variable:

window.search = function() {
    ...
}