Visual C++: Exporting decorated function name in a def file

Question

I want to export a decorated function name in a def file like this:

LIBRARY Example
EXPORTS
??0__non_rtti_object@std@@QAE@ABV01@@Z=myfunc @1

Th

Answer 1

Preamble

You didn't answer my comment about the use of the .DEF file, so I assume you must be unfamiliar with the the dllexport and dllimport qualifiers. With them, there is no need for the .DEF file to export symbols.

If there is a particular need for the .DEF file that invalidate the use of the dllimport/dllexport feature, please ignore the following.

How to use dllimport/dllexport?

In your public header (say, public.hpp), write something like:

#ifdef MY_PROJECT_EXPORTS
   #define MY_PROJECT_API __declspec(dllexport)
#else
   #define MY_PROJECT_API __declspec(dllimport)
#endif

This way, the macro MY_PROJECT_API will enable the export/import of your symbols. For example, later, in the same public.hpp, you can declare:

// A global variable
MY_PROJECT_API int myGlobalVariable ;

// A function
MY_PROJECT_API void my_function() ;

// A class or struct
class MY_PROJECT_API MyClass
{
   public :
      int i;
      virtual int foo() ;
      // etc.
} ;

Then, what you need to do is, in the project options of your library, define the MY_PROJECT_EXPORTS: This way, when you compile your library, the symbols above are declared dllexport, and when someone else includes your public.hpp header, the symbols above will be dllimport

And if your code is cross-platform (dllimport/dllexport is a MS compiler feature), just wrap the defines above around a compiler test. For example:

#ifdef _MSC_VER
   // For MS Visual Studio
   #ifdef MY_PROJECT_EXPORTS
      #define MY_PROJECT_API __declspec(dllexport)
   #else
      #define MY_PROJECT_API __declspec(dllimport)
   #endif
#else
   // For other compilers
   #define MY_PROJECT_API
#endif

About the .DEF file?

The .DEF file was used before, when exportable C functions were still "the way to go" on Visual Studio.

For strong type safety, C++ decorate its symbols.

The downside is that each compiler has its own decoration scheme (which never bothered me in 12-years of development), and that finding the exact, decorated name of a symbol can't be painful.

But the merits of that is that:

1. You can now export overloaded/namespaced functions/symbols
2. the parameter types are part of the ABI, meaning the linker can verify you aren't screwing up or cheating with your types

The dllimport and dllexport features have the following advantages:

1. it enables the export to be done at source level, instead of using yet another project file
2. the programmer can now ignore the particular decoration scheme (which usually only interests the linker), all the while profiting from the strong type safety of C++ extended to the linker.

Sources

For more information, see:

• __declspec : http://msdn.microsoft.com/en-us/library/dabb5z75.aspx
• dllexport, dllimport : http://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx
• Using dllimport and dllexport in C++ Classes : http://msdn.microsoft.com/en-us/library/81h27t8c.aspx