🔒 Locked

C++ name mangling

Started by Songoku Dec 22, 2004 at 2:12 PM 17 replies 2.7k views

Original Post

Dec 22, 2004 at 2:12 PM

Because of different name-mangling-shemas of different compilers nobody can be sure that the function: void Add(∫, ∫) has the equivalent string name: "Add". And i want to get the name of a method of a class(for example void CWindow::CreateWindow()). Is there a way to get the c++ name-magled name of a function into a TextFile or into a string or char* or into a binary file(getting into a char* will be enough ;). There is no problem to save the char* into a text or binary file later on)???

Songoku

Author

Songoku

Dec 22, 2004 at 2:35 PM

Is there a solution??? I need help!

Xai

344

Xai

Dec 22, 2004 at 2:42 PM

the first part of your questions is that you use:

extern "C"

to tell the compiler not to use name mangling on top level functions ...

but I don't know what you do for your member function question.

Songoku

Author

Songoku

Dec 22, 2004 at 2:47 PM

do you know the answer for static method of a class like that:
class A
{
static void Add(int, int);
};

Lord Bart

Dec 22, 2004 at 2:51 PM

Hello Songoku,

? why do you want to save the mangling names?

You should be able to was the linker form your compiler or system to output names of functions and file level vars contained in a library or object file.
Since it is the library program that packages obj file into library it also should list out what is in them.

Not sure what the library program is called on windows.

For static member you can extern "C" it also as long as you don't have another function the same name.

exten "C" static void Add(int, int);

Lord Bart :)

Songoku

Author

Songoku

Dec 22, 2004 at 2:55 PM

i want to get the n magled name because i want to load a method of a class from a dll into the client application but do not know the name of the method because it is mangled.

Can i use extern "C" for static memmber functions too???

Lord Bart

Dec 22, 2004 at 3:01 PM

Hello Songoku,

Ok, I understand, but I will point out something to you about use code compiler by different vendors compilers.

The name mangling can be different but also the calling convertion, class/struct layout.

So even if you get the mangled name you still might have problems use it.
Because it up to the on vendor how they do there classes.
prime example is the virtaul function tables.

This is very important thing to understand.

Lord Bart :)

Songoku

Author

Songoku

Dec 22, 2004 at 3:08 PM

i have thougth long about this think. And i have a good solution.
my lient app has an pointer to an interface class. The dll inherits from this class. So i have no problems with virtual function tables because every compiler has to have equivalent virtual function tables for pure virtual functions inside a class or interface classes. i read an article about this. But i do not want to have a global function in an dll because i want to be as much OO as possible and if it is possible to get the mangled name i could program with every envirement and my client app would have no problems.

chollida1

Dec 22, 2004 at 3:12 PM

You can always load the dll and call getprocaddress with the undecorated name. That's always guarenteed to work. Or if you want to link in a dll built with another compiler you can use a defs file.

Those two options should cover most cases. Do you have another case where this wouldn't work??

Cheers
Chris

Songoku

Author

Songoku

Dec 22, 2004 at 3:29 PM

when i have a class:
class A
{
public:
__declspec(dllexport) static void B() {}
};

and want to get the adress of B() i cannot write in the client app:
GetProcAddress(m_Lib, "B");
or
GetProcAddress(m_Lib, "A::B");

the function is not found. i need the mangled name.

Mayrel

Dec 22, 2004 at 3:42 PM

All in all: a bad idea.

Your program wouldn't survive moving to another compiler, and might not even survive upgrading to another version of your current compiler.

There is no portable way to automatically determine the mangled name of a function within C++ itself.

I'd make an extern "C" wrapper around A::B. You might call it "A_B", for example.

Lord Bart

Dec 22, 2004 at 3:42 PM

Ok you have a class that has a pointer to the actual class and you only call the interface methods, which into in the dll code call the imp class member function.

Thats fine, but you need to make sure that params and return things are compatable between, if one compile doesn't pad and the other did you have a problem.

If any data members are base off of size that a compiler can set then you got a problem.

ex:
size_t is compiler defined sometimes.
bool is compiler defined all the time.
if compiler A has bool is one byte and compiler B has bool is 4 bytes then you have big problem.

Lord Bart :)

Songoku

Author

Songoku

Dec 22, 2004 at 3:45 PM

if it does not work i can only export a global function to the dll and inport this
function via getprocaddress to create an object of the derived class. So everything is going very well. but i searched a way of getting this function into the class implementation to be OO. But it seems not to work.

Lord Bart

Dec 22, 2004 at 4:02 PM

Hello Songoku,

If you truly want to use classes compile by one complier with another then you need to follow a few steps.

1) make sure data members are compiler netural in size as possible.
ie. try to avoid bool and size_t. Unless you veryified there the same size on both compilers.

2) try to make sure same calling convection are used.

3) warp class methods in C callable code.

4) Do not create any classes/structure use in dll on your own by new or on the stack.
Use only a Create method from the dll to return you a pointer to class/structure.
This assure you the class is created properly by the compler code that controls the class ie the dll in question.

This way you can still hold pointers to class from the other compiler and if you want to acces a method you call C funtion with passed in pointer of class.

There is a reason why most of windows API is C callabe so other compilers can use them.

Lord Bart :)

Songoku

Author

Songoku

Dec 22, 2004 at 4:15 PM

Yes i know that it has to be so. Thanks for the reply.

antareus

Dec 22, 2004 at 6:19 PM

Quote:
Original post by Songoku
class implementation to be OO. But it seems not to work.

Global functions are merely static member functions, except not within a class. If you think OO has everything to do with using the class keyword, then you are missing the point.

Doc

Dec 22, 2004 at 6:51 PM

Fruny showed his solution to the opposite problem, going from mangled to non, in this thread. It might give you some clues as to where to look. Maybe [google] C++ ABI.

Arild Fines

138

Arild Fines

Dec 23, 2004 at 8:09 AM

Quote:
Original post by antareus
Quote:
Original post by Songoku
class implementation to be OO. But it seems not to work.

Global functions are merely static member functions, except not within a class.

That's not entirely true, though. A static member function has access to private members of its class, both static and non-static.

Whether that's desirable or not is another discussion...

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.