我在调用别人的dll的时候，用depends分析了一下对方的函数，发现函数名怎么那么长，而且有很多特殊符号

[yanghaiyanghai]

下面这个是我用depends分析出来对方dll里面的函数名，而实际上对方提供的文档中的函数名其实不是这样的，比如都是这样：EMErrorPtr login(const std::string &username, const std::string &password);

我想求教大家，为什么通过depends分析出来的函数名字是下面这样的带?或者@符号，因为这样我通过动态的方式调用dll里面的函数的时候基本上就调不到，总提示未找到对应的函数，望大家提供一下参考意见。

??0EMContactManagerInterface@easemob@@QAE@XZ
??0EMConversation@easemob@@AAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4EMConversationType@01@0@Z
??0EMCursorResult@easemob@@QAE@ABV01@@Z
??0EMCursorResult@easemob@@QAE@ABV?$vector@V?$shared_ptr@VEMBaseObject@easemob@@@std@@V?$allocator@V?$shared_ptr@VEMBaseObject@easemob@@@std@@@2@@std@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@3@@Z
??0EMEncryptProviderInterface@easemob@@QAE@ABV01@@Z
??0EMEncryptProviderInterface@easemob@@QAE@XZ
??0EMError@easemob@@QAE@ABV01@@Z
??0EMError@easemob@@QAE@HABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z
??0EMFileMessageBody@easemob@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4EMMessageBodyType@EMMessageBody@1@@Z
??0EMFileMessageBody@easemob@@QAE@W4EMMessageBodyType@EMMessageBody@1@@Z
??0EMGroup@easemob@@AAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z
??0EMGroupManagerInterface@easemob@@QAE@ABV01@@Z
??0EMGroupManagerInterface@easemob@@QAE@XZ
??0EMGroupManagerListener@easemob@@QAE@ABV01@@Z
??0EMGroupManagerListener@easemob@@QAE@XZ
??0EMGroupSetting@easemob@@QAE@ABV01@@Z
??0EMGroupSetting@easemob@@QAE@W4EMGroupStyle@01@H@Z
??0EMImageMessageBody@easemob@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z
??0EMImageMessageBody@easemob@@QAE@XZ
??0EMJsonString@easemob@@QAE@ABV01@@Z
??0EMJsonString@easemob@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z

[smwhotjay]

c++的导出名字一长串。。但依然有规律 的 c的导出名字如果指定了，那么可以是很简短的。只要不冲突。

[oyljerry]

主要是一些参数描述，以及函数调用约定的描述。

[zgl7903]

http://www.cppblog.com/FateNo13/archive/2009/08/03/92052.html

[赵4老师]

dll 导出函数名的那些事 关键字：　VC++ 　DLL 导出函数　 经常使用VC6的Dependency查看DLL导出函数的名字，会发现有DLL导出函数的名字有时大不相同，导致不同的原因大多是和编译DLL时候指定DLL导出函数的界定符有关系。 VC++支持两种语言：即C/C++，这也是造成DLL导出函数差异的根源 我们用VS2008新建个DLL工程，工程名为"TestDLL" 把默认的源文件后缀 .CPP改为.C（C文件） 输入测试代码如下： 01 int _stdcall MyFunction(int iVariant) 02 { 03 return 0; 04 } 为了导出上面这个函数，我们有以下几个方法： 1. 使用传统的模块定义文件 (.def) 新建一个 后缀为.def的文本文件(这里建一个TestDll.Def)，文件内容为： LIBRARY TestDll EXPORTS MyFunction 在 Link 时指定输入依赖文件：/DEF:"TestDll.Def" 2. Visual C++ 提供的方便方法 在01行的int 前加入 __declspec(dllexport) 关键字 通过以上两种方法，我们就可以导出MyFunction函数。 我们用Dependency查看导出的函数： 第一种方法导出的函数为： MyFunction 第二种方法导出的函数为： _MyFunction@4 __stdcall会使导出函数名字前面加一个下划线，后面加一个@再加上参数的字节数，比如_MyFunction@4的参数（int iVariant）就是4个字节 __fastcall与 __stdcall类似，不过前面没有下划线，而是一个@，比如@MyFunction@4 __cdecl则是始函数名。 小结：如果要导出C文件中的函数，并且不让编译器改动函数名，用def文件导出函数。 下面我们来看一下C++文件 我们用VS2008新建个DLL工程，工程名为"TestDLL" 默认的源文件后缀为 .CPP （即C++文件）。 输入测试代码如下： 01 int _stdcall MyFunction(int iVariant) 02 { 03 return 0; 04 } 为了导出上面这个函数，我们有以下几个方法： 3. 使用传统的模块定义文件 (.def) 新建一个 后缀为.def的文本文件(这里建一个TestDll.Def)，文件内容为： LIBRARY TestDll EXPORTS MyFunction 在 Link 时指定输入依赖文件：/DEF:"TestDll.Def" 4. Visual C++ 提供的方便方法 在01行的int 前加入 __declspec(dllexport) 关键字 通过以上两种方法，我们就可以导出MyFunction函数。 我们用Dependency查看导出的函数： 第一种方法导出的函数为： MyFunction 第二种方法导出的函数为： ?MyFunction@@YGHH@Z 可以看到 第二种方法得到的 导出函数名 并不是我们想要的，如果在exe中用显示方法（LoadLibrary、GetProcAddress）调用 MyFunction 肯定会失败。 但是用引入库(*.LIB)的方式调用，则编译器自动处理转换函数名，所以总是没有问题。 解决这个问题的方法是： 用VC 提供的预处理指示符 "#pragma" 来指定链接选项。 如下： #pragma comment(linker, "/EXPORT:MyFunction=?MyFunction@@YGHH@Z") 这时，就会发现导出的函数名字表中已经有了我们想要的MyFunction。但我们发现原来的那个 ?MyFunction@@YGHH@Z 函数还在，这时就可以把 __declspec() 修饰去掉，只需要 pragma 指令即可。 而且还可以使如下形式： #pragma comment(linker, "/EXPORT:MyFunction=_MyFunction@4,PRIVATE") PRIVATE 的作用与其在 def 文件中的作用一样。更多的#pragram请查看MSDN。 小结：如果要导出C++文件中的函数，并且不让编译器改动函数名，用def文件导出函数。 同时可以用#pragma指令（C 中也可以用）。 总结： C++编译器在生成DLL时，会对导出的函数进行名字改编，并且不同的编译器使用的改编规则不一样，因此改编后的名字也是不同的（一般涉及到C++ 中的重载等）。 如果利用不同编译器分别生成DLL和访问DLL的exe程序，后者在访问该DLL的导出函数时就会出现问题。如上例中函数MyFunction在C++编译器改编后的名字是?MyFunction@@YGHH@Z。我们希望编译后的名字不发生改变，这里有几种方法。 第一种方法是通过一个称为模块定义文件DEF来解决。 LIBRARY TestDll EXPORTS MyFunction LIBRARY 用来指定动态链接库内部名称。该名称与生成的动态链接库名一定要匹配，这句代码不是必须的。 EXPORTS说明了DLL将要导出的函数，以及为这些导出函数指定的符号名。 第二种是定义导出函数时加上限定符：extern "C" 如：#define DLLEXPORT_API extern "C" _declspec(dllexport) 但extern "C"只解决了C和C++语方之间调用的问题(extern "C" 是告诉编译器，让它按C的方式编译)，它只能用于导出全局函数这种情况 而不能导出一个类的成员函数。 同时如果导出函数的调用约定发生改变，即使使用extern "C"，编译后的函数名还是会发生改变。例如上面我们加入_stdcall关键字说明调用约定（标准调用约定，也就是WINAPI调用约定）。 #define DLLEXPORT_API extern "C" _declspec(dllexport) 01 DLLEXPORT_API int _stdcall MyFunction(int iVariant) 02 { 03 return 0; 04 } 编译后函数名MyFunction改编成了_MyFunction@4 通过第一种方法模块定义文件的方式DLL编译后导出函数名不会发生改变。 DLL(动态库)导出函数名乱码含义 C++编译时函数名修饰约定规则： __stdcall调用约定： 1、以"?"标识函数名的开始，后跟函数名； 2、函数名后面以"@@YG"标识参数表的开始，后跟参数表； 3、参数表以代号表示： X--void D--char E--unsigned char F--short H--int I--unsigned int J--long K--unsigned long M--float N--double _N--bool .... PA--表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以"0"代替，一个"0"代表一次重复； 4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前； 5、参数表后以"@Z"标识整个名字的结束，如果该函数无参数，则以"Z"标识结束。 其格式为"?functionname@@YG*****@Z"或"?functionname@@YG*XZ"，例如 int Test1(char *var1, unsigned long)-----"?Test1@@YGHPADK@Z" void Test2()-----"?Test2@@YGXXZ" __cdecl调用约定： 规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YA"。 __fastcall调用约定： 规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YI"。 如果要用DEF文件输出一个"C++"类，则把要输出的数据和成员的修饰名都写入.def模块定义文件 所以... 通过def文件来导出C++类是很麻烦的,并且这个修饰名是不可避免的

[yanghaiyanghai]

引用 5 楼 homesos 的回复:

你都有.h了，不如静态调用。 如果要动态调用，就要把查找的名称弄成跟导出的名称一样的：??0EMEncryptProviderInterface@easemob@@QAE@ABV01@@Z，之所以这么长是为了防止函数重名，C++里有类方法、重载都会重名。

我已经通过工具把接口里面的函数给翻译出来了，如下：能够帮忙指导1，3个函数看怎么翻译吗？ class std::shared_ptr<class easemob::EMError> easemob::EMChatClient::createAccount(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &) class std::shared_ptr<class easemob::EMError> easemob::EMClient::createAccount(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)

[赵4老师]

UnDecorateSymbolName The UnDecorateSymbolName function undecorates decorated C++ symbol names. DWORD UnDecorateSymbolName( IN LPSTR DecoratedName, OUT LPSTR UnDecoratedName, IN DWORD UndecoratedLength, IN DWORD Flags ); Parameters DecoratedName Pointer to a null-terminated string that specifies a decorated C++ symbol name. This name can be identified by the first character of the name, which is always a question mark (?). UnDecoratedName Pointer to a null-terminated string that specifies the buffer that receives the undecorated name. UndecoratedLength Specifies the length of the UnDecoratedName buffer. Flags Specifies how the decorated name is undecorated. This parameter can be zero or any combination of the following values: Value Description UNDNAME_COMPLETE Enable full undecoration. UNDNAME_NO_LEADING_UNDERSCORES Remove leading underscores from Microsoft keywords. UNDNAME_NO_MS_KEYWORDS Disable expansion of Microsoft keywords. UNDNAME_NO_FUNCTION_RETURNS Disable expansion of return types for primary declarations. UNDNAME_NO_ALLOCATION_MODEL Disable expansion of the declaration model. UNDNAME_NO_ALLOCATION_LANGUAGE Disable expansion of the declaration language specifier. UNDNAME_NO_MS_THISTYPE Disable expansion of Microsoft keywords on the this type for primary declaration. UNDNAME_NO_CV_THISTYPE Disable expansion of CodeView modifiers on the this type for primary declaration. UNDNAME_NO_THISTYPE Disable all modifiers on the this type. UNDNAME_NO_ACCESS_SPECIFIERS Disable expansion of access specifiers for members. UNDNAME_NO_THROW_SIGNATURES Disable expansion of throw-signatures for functions and pointers to functions. UNDNAME_NO_MEMBER_TYPE Disable expansion of the static or virtual attribute of members. UNDNAME_NO_RETURN_UDT_MODEL Disable expansion of Microsoft model for UDT returns. UNDNAME_32_BIT_DECODE Undecorate 32-bit decorated names. UNDNAME_NAME_ONLY Crack only the name for primary declaration. Returns [scope::]name. Does expand template parameters. UNDNAME_NO_ARGUMENTS Do not undecorate function arguments. UNDNAME_NO_SPECIAL_SYMS Do not undecorate special names, such as vtable, vcall, vector, metatype, and so on. Return Values If the function succeeds, the return value is the number of characters in the UnDecoratedName buffer, not including the NULL terminator. If the function fails, the return value is zero. To retrieve extended error information, call GetLastError. Remarks If the function fails and returns zero, the content of the UnDecoratedName buffer is undetermined. QuickInfo Windows NT: Requires version 4.0 or later. Windows: Requires Windows 95 or later. Available as a redistributable for Windows 95. Windows CE: Unsupported. Header: Declared in imagehlp.h. Import Library: Use imagehlp.lib. See Also PE Image Helper (ImageHlp) Overview, ImageHlp Debugger Functions

[赵4老师]

class std::shared_ptr<class easemob::EMError>
easemob::EMChatClient::createAccount(
    class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,
    class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &
)

class std::shared_ptr<class easemob::EMError>
easemob::EMClient::createAccount(
    class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,
    class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &
)

[homesos]

你都有.h了，不如静态调用。 如果要动态调用，就要把查找的名称弄成跟导出的名称一样的：??0EMEncryptProviderInterface@easemob@@QAE@ABV01@@Z，之所以这么长是为了防止函数重名，C++里有类方法、重载都会重名。