Difference between revisions of "DIP45"

From D Wiki
Jump to: navigation, search
m (fix typo ("exoport"))
Line 1: Line 1:
 
{| class="wikitable"
 
{| class="wikitable"
 
!Title:
 
!Title:
!'''export(identifier)'''
+
!'''making export an attribute'''
 
|-
 
|-
 
|DIP:
 
|DIP:
Line 16: Line 16:
 
|-
 
|-
 
|Last Modified:
 
|Last Modified:
|2013-08-27
+
|2013-08-30
 
|-
 
|-
 
|Author:
 
|Author:
Line 23: Line 23:
 
|Links:
 
|Links:
 
|http://forum.dlang.org/post/5112D61B.5010905@digitalmars.com
 
|http://forum.dlang.org/post/5112D61B.5010905@digitalmars.com
 +
http://forum.dlang.org/post/kvhu2c$2ikq$1@digitalmars.com
 
http://d.puremagic.com/issues/show_bug.cgi?id=9816
 
http://d.puremagic.com/issues/show_bug.cgi?id=9816
 
|}
 
|}
Line 28: Line 29:
 
==Abstract==
 
==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.
+
Export and its behavior needs to be changed in serveral ways to make it work on Windows and allow better code generation for other plattforms. The Rationale section explains the problem and shows how this DIP solves it.
  
 
==Description==
 
==Description==
  
The 'export' protection level should be extended by a identifier so that
+
* The 'export' protection level should be turned into a 'export' attribute.
 
+
* If a module contains a single symbol annotated with the 'export' attribute all compiler internal symbols of this module should recieve the 'export' attribute too (e.g. module info).
export void libraryFunction();
+
* If a class is annotated with the 'export' attribute, all of its public and protected functions and members will automatically recieve the 'export' attribute. Also all its hidden compiler specific symbols will recieve the 'export' attribute.
 
+
* It should be possible to access TLS variables which are stored in a DLL / shared library.
becomes
 
 
 
export(exampleLib) void libraryFunction();
 
 
 
Also two new command line 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==
 
==Rationale==
  
The 'export' protection level was originally designed to work as the equivalent of C++ __declspec(dllimport) and __declspec(dllexport) at the same time.
+
Work in progress
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
 
<syntaxhighlight lang=D>
 
module libA;
 
 
export(libA):
 
 
__gshared int libAVar;
 
int libAFunc()
 
{
 
  return 5;
 
}
 
</syntaxhighlight>
 
 
 
 
 
<syntaxhighlight lang=D>
 
module libB:
 
import libA;
 
 
export(libB):
 
 
int libBFunc()
 
{
 
  return libAFunc() + libAVar;
 
}
 
</syntaxhighlight>
 
 
 
 
 
<syntaxhighlight lang=D>
 
module main;
 
import libA;
 
import libB;
 
 
void main(string[] args)
 
{
 
  printf("%d %d", libAFunc(), libBFunc());
 
}
 
</syntaxhighlight>
 
 
 
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
+
==Implementation Details==
  
dmd -m64 -import libB -import libA main.d -LlibA.lib -LlibB.lib
+
Work in progress
  
 
== Copyright ==
 
== Copyright ==

Revision as of 15:48, 30 August 2013

Title: making export an attribute
DIP: 45
Version: 1
Status: Draft
Created: 2013-08-27
Last Modified: 2013-08-30
Author: Benjamin Thaut
Links: http://forum.dlang.org/post/5112D61B.5010905@digitalmars.com

http://forum.dlang.org/post/kvhu2c$2ikq$1@digitalmars.com http://d.puremagic.com/issues/show_bug.cgi?id=9816

Abstract

Export and its behavior needs to be changed in serveral ways to make it work on Windows and allow better code generation for other plattforms. The Rationale section explains the problem and shows how this DIP solves it.

Description

  • The 'export' protection level should be turned into a 'export' attribute.
  • If a module contains a single symbol annotated with the 'export' attribute all compiler internal symbols of this module should recieve the 'export' attribute too (e.g. module info).
  • If a class is annotated with the 'export' attribute, all of its public and protected functions and members will automatically recieve the 'export' attribute. Also all its hidden compiler specific symbols will recieve the 'export' attribute.
  • It should be possible to access TLS variables which are stored in a DLL / shared library.

Rationale

Work in progress

Implementation Details

Work in progress

Copyright

This document has been placed in the Public Domain.