name-mangling

While sitting on a mushroom and contemplating the intricacies of inscribing a function to implement Python's name mangling algorithm, a stupendously better idea came into my noggin. Why not use the recipe already crafted into the language to accomplish such a goal? So I pulled ctypes out of my satchel to help with the endeavor and executed ctypes.pythonapi._Py_Mangle('Demo', '__test') . Lo and behold, an error appeared out of thin air saying OSError: exception: access violation reading 0x00000A65646F00A8 and did not bother to explain the conundrum any more than that. The full interaction with

How can I find out the decorated name that will be asigned to each method name ? I'm trying to find out what the decorated name is , so that I may export it , in a DLL . .DEF file are still being used? Forget .DEF files. They are a thing of the past. Export your functions, be them C functions or C++ symbols, through __declspec(dllimport/dllexport). If you really need undecorated names, use as suggested by Greg Hewgill, the __declspec(dllimport/dllexport) keywords, combined with extern "C", which will strip those symbols of their decoration... Are you sure you want to remove the C++ decoration?

I have a C++ object file that contains instantiations of some C++ template functions. The object file in question instantiates the same function for a few different combinations of template parameters. I'm trying to debug a problem and would like to look at the disassembly of a specific instantiation of the template function (that is, I know the template parameters for the function that I want to examine). I would typically do this using objdump to disassemble the object file, but it (at least by default) isn't able to de-mangle the C++ function names. Is there any way to do this? The object

I am facing linker error for a XERCES function while upgrading it from 2.6 to 2.8 unresolved external symbol (?resolveEntity@HandlerBase@xercesc_2_8@@UAEPAVInputSource@2@QBG0@Z) I checked the xerces-c_2.8.lib and found that name lib is bit different that the one in my .obj file It is as shown ?resolveEntity@HandlerBase@xercesc_2_8@@UAEPAVInputSource@2@QB_W0@Z So I understand that linker wont find the match and throw error. But I am unable to understand why my .obj file contains different signature. code is including correct header files and lib from still incorrect name. Any help would be

Looking around, I see mostly questions about demangling C++ symbols rather than how to mangle them. Yes, one could invoke g++ , using the -S option, on some dummy code containing the symbols to be mangled, and then examine the resulting assembly, but I haven't been able to find a good reference or specification on GCC's name mangling. The closest thing I could find was at http://www.int0x80.gr/papers/name_mangling.pdf , but it doesn't seem to cover things like how names template instantiations are mangled or why _Z3fooIN3BarEE3FooIXT_EEv would translate into Foo<Bar> foo<Bar>() (though I can

Consider the following do-nothing code, which I am compiling as C++ on Win10 64-bit: int test(int argc, char *argv[]); int main(int argc, char *argv[]) { return test(argc, argv); } int test(int argc, char **argv) { return 0; } If all of this code is placed in the same .cpp file it compiles and links correctly in VS2012, VS2013, VS2015, and mingw32-g++ v4.7.1, as I would expect it to. However, if I simply move the definition of the test function into a separate file the resulting two files still compile and link correctly with the mingw compiler but on all versions of VS I get: error LNK2019:

I would like to print the name of a type for debugging purposes, so I've created a function which does the trick (in fact, I borrowed it from another SO answer, which I cannot found now), the function looks like this: template <typename T> std::string TypeName(T) { auto name = typeid(T).name(); int status = 0; std::unique_ptr<char, void(*)(void*)> res { abi::__cxa_demangle(name, NULL, NULL, &status), std::free }; return ((status == 0) ? res.get() : name); } Live Demo It works fine: int i = 0; float f = 0.f; std::cout << TypeName(i) << '\n'; // int std::cout << TypeName(f) << '\n'; // float, so