Name mangling
Очень нужна информация по менглированию имен методов классов в Borland C++ [Builder].
Заранее спасибо за ответы.
Доброго всем времени суток
Очень нужна информация по менглированию имен методов классов в Borland C++ [Builder].
Заранее спасибо за ответы.
Calling convention mangling compatibility option
(Command-line switch: -VC)
When this option is set, the compiler disables the distinction of function names where the only possible difference is incompatible code generation options. For example, with this option set, the linker will not detect if a call is made to a _ _fastcall member function with the cdecl calling convention.
This option is provided for backward compatibility only; it lets you link old library files that you cannot recompile.
Default = OFF
Name mangling
When a C++ module is compiled, the compiler generates function names that include an encoding of the function's argument types. This is known as name mangling. It makes overloaded functions possible, and helps the linker catch errors in calls to functions in other modules. However, there are times when you won't want name mangling. When compiling a C++ module to be linked with a module that does not have mangled names, the C++ compiler has to be told not to mangle the names of the functions from the other module. This situation typically arises when linking with libraries or .OBJ files compiled with a C compiler
To tell the C++ compiler not to mangle the name of a function, declare the function as extern "C", like this:
extern "C" void Cfunc( int );
This declaration tells the compiler that references to the function Cfunc should not be mangled.
You can also apply the extern "C" declaration to a block of names:
extern "C" {
void Cfunc1( int );
void Cfunc2( int );
void Cfunc3( int );
};
As with the declaration for a single function, this declaration tells the compiler that references to the functions Cfunc1, Cfunc2, and Cfunc3 should not be mangled. You can also use this form of block declaration when the block of function names is contained in a header file:
extern "C" {
#include "locallib.h"
};
Note: extern “C” cannot be used with class identifiers.
ЗЫ Borlan C++ Bulder v6.0 Help
Это все понятно, а как быть с построением имени метода. Например:
Не понял.
Пример такого имени я приводил выше. Все, что идет после собак - понятно что, после $ же идут описание аргументов и возвращаемого значения (их типы). Хотелось бы узнать, как построить строку после $ для Borland C++ Builder.
Прошу прощения за изначально неполноценно поставленный вопрос.
В общем, мне нужно неявно использовать некоторые методы класса, экспортируемые из DLL. При вызове GetProcAddress я в параметре "имя процедуры" указываю менглированное имя, которое компилятор Borland C++ использует для генерирования уникального имени данного метода.
Пример такого имени я приводил выше. Все, что идет после собак - понятно что, после $ же идут описание аргументов и возвращаемого значения (их типы). Хотелось бы узнать, как построить строку после $ для Borland C++ Builder.
Прошу прощения за изначально неполноценно поставленный вопрос.
Может это поможет?
Classes in a DLL
IMPDEF is useful for a DLL that uses C++ classes. If you use the __declspec (or _export) keyword when defining a class, all of the non-inline member functions and static data members for that class are exported. It's easier to let IMPDEF make a module definition file for you because it lists all the exported functions, and automatically includes the member functions and static data members.
Since the names of these functions are mangled, it would be tedious to list them all in the EXPORTS section of a module definition file simply to create an import library from the module definition file. If you use IMPDEF to create the module definition file, it will include the ordinal value for each exported function. If the exported name is mangled, IMPDEF will also include that function's unmangled, original name as a comment following the function entry. So, for instance, the module definition file created by IMPDEF for a DLL that used C++ classes would look something like this:
LIBRARY FileName
DESCRIPTION 'Description'
EXPORTS
MangledExportFuncName @Ordinal ; ExportFuncName
.
.
.
MangledExportFuncName @Ordinal ; ExportFuncName
where
FileName is the DLL's root file name
Description is the value of the DESCRIPTION statement if the DLL was previously linked with a module definition file that included a DESCRIPTION statement
MangledExportFuncName provides the mangled name
Ordinal is that function's ordinal value (an integer)
ExportFuncName gives the function's original name.
Import libraries provide access to the functions in a Windows DLL.
IMPDEF takes as input a DLL name, and produces as output a module definition file with an export section containing the names of functions exported by the DLL.
The syntax is:
IMPDEF DestName.DEF SourceName.DLL
This creates a module definition file named DestName.DEF from the file SourceName.DLL. The resulting module definition file would look something like this:
LIBRARY FileName
DESCRIPTION 'Description'
EXPORTS
ExportFuncName @Ordinal
.
.
.
ExportFuncName @Ordinal
where:
FileName is the DLL's root file name
Description is the value of the DESCRIPTION statement if the DLL was previously linked with a module definition file that included a DESCRIPTION statement
ExportFuncName names an exported function
Ordinal is that function's ordinal value (an integer).
Option Description
-a Add '_' alias for cdecl functions for compatibility with Microsoft libraries
-h Emit hints
Да, это действительно поможет. IMPDEF выдает то, что нужно. СПАСИБО