DIP45

Title:	exoport(identifier)
DIP:	45
Version:	1
Status:	Draft
Created:	2013-08-27
Last Modified:	2013-08-27
Author:	Benjamin Thaut
Links:	http://forum.dlang.org/post/5112D61B.5010905@digitalmars.com http://d.puremagic.com/issues/show_bug.cgi?id=9816

Abstract

Add a identifier to the export protection level to make it useable for dll import/export on windows platforms. The Rationale section explains the problem and shows how this DIP solves it.

Description

The 'export' protection level should be extended by a identifier so that

export void libraryFunction();

becomes

export(exampleLib) void libraryFunction();

Also two new command lines parameters should be added to the compiler:

• "-import identifier": which turns all export protected symbols with a matching identifier into dllimport
• "-export identifier": which turns all export protected symbols with a matching identifier into dllexport

If none of the above two compiler options is given for a export(identifier) protection it does not have any effect at all.

For backwards compatibility export without a identifier will become export(default) implicitly. When transitioning to this new system no code needs to be changed. Only "-import default" and "-export default" needs to be added when compiling.

On platforms not requiring dllimport/dllexport the command line parameters are not available and the export protection level does not have any effect.

Rationale

The 'export' protection level was originally designed to work as the equivalent of C++ __declspec(dllimport) and __declspec(dllexport) at the same time. This however does not work, as the compiler cannot know without giving it additional context which 'export' are dllimport, which are dllexport and which are to be ignored.

Consider the following example: Two libraries A and B exists. Both of them are used by an executable. The library B uses library A.

• While compiling library A as shared library all 'export' protected symbols inside the source of A need to be treated as dllexport.
• While compiling library B as shared library all 'export' protected symbols inside the source of A need to be treated as dllimport. All 'export' protected symbols inside the source of B need to be treated as dllexport.
• When compiling the executable all 'export' protected symbols inside the source of A and B need to be treated as dllimport.
• When compiling library A or B as static library 'export' should not have any effect at all.

Usign the identifier and command lines switches proposed in this DIP makes it possible to cover all of the above cases. Please also note that the exact same source code can be used to cover all the above cases. Using .di files is possible but not required to make it work.

Using this DIP the above example implemented might look as follows

module libA;
 
export(libA):
 
__gshared int libAVar;
int libAFunc()
{
  return 5;
}

module libB:
import libA;
 
export(libB):
 
int libBFunc()
{
  return libAFunc() + libAVar;
}

module main;
import libA;
import libB;
 
void main(string[] args)
{
  printf("%d %d", libAFunc(), libBFunc());
}

Compiling libA as shared library

dmd -m64 -export libA -of"libA.dll" dllmain.d libA.d -L/DLL -L/IMPLIB:"libA.lib"

Compiling libB as shared library

dmd -m64 -export libB -import libA -of"libB.dll" dllmain.d libB.d -L/DLL -L/IMPLIB:"libB.lib" -LlibA.lib

Compiling the executable

dmd -m64 -import libB -import libA main.d -LlibA.lib -LlibB.lib

Copyright

This document has been placed in the Public Domain.