Difference between revisions of "DIP45"

From D Wiki
Jump to: navigation, search
(Rationale)
Line 78: Line 78:
  
 
In the above example 'DoSomething' should only be visible to derived classes but should still be exported from a shared library. This does not work with the current implementation of 'export'. Turning 'export' into an attribute will make this work.
 
In the above example 'DoSomething' should only be visible to derived classes but should still be exported from a shared library. This does not work with the current implementation of 'export'. Turning 'export' into an attribute will make this work.
 +
 +
===Implicitly exporting compiler internal symbols of a module===
 +
 +
Currently compiler internal symbols of modules are not exported at all. This leads to liner errors when linking against shared libraries on windows. By marking compiler internal symbols as 'export' as soon as there is a single exported symbol in the module will fix this problem.
 +
 +
===export attribute inferrence===
 +
 +
Currently export has to be specified in a lot of places to export all neccessary functions and data symbols. Export should be transitive in such a sense that it only needs to be specified once in a module to export all of its functions / data members including classes and their members / data symbols. Consider the following example:
 +
 +
<syntaxhighlight lang=D>
 +
module sharedLib:
 +
 +
export:
 +
 +
__gshared int g_Var; // should be exported
 +
 +
void globalFunc() { ... } // should be exported
 +
 +
class A // compiler internal members should be exported
 +
{
 +
  private:
 +
    int m_a;
 +
 +
    static int s_b; // should not be exported
 +
 +
    void internalFunc() { ... } // should not be exported
 +
 +
  protected:
 +
    void interalFunc2() { ... } // should be exported
 +
 +
  public:
 +
    class Inner // compiler internal members should be exported
 +
    {
 +
      static s_inner; // should be exported
 +
 +
      void innerMethod() { ... } // should be exported
 +
    }
 +
 +
    void method() { ... } // should be exported
 +
}
 +
 +
private class C // should not be exported
 +
{
 +
  public void method() { ... } // should not be exported
 +
}
 +
</syntaxhighlight>
 +
 +
===Access TLS variables===
 +
 +
Currently it is not possible to acces TLS variables across shared library boundaries. This should be implemented. See implementation details.
 +
 +
===Change symbol visibility on *nix systems===
 +
 +
When building shared libraries on *nix systems all symbols are visible by default. This can lead to long loading time of shared libraries if they contain a large number of symbols.
 +
Also everything visible by deafult makes it hard to commit to a certain stable interface, as one has no control over the visible symbols.
  
 
==Implementation Details==
 
==Implementation Details==
  
Work in progress
+
=== Windows ===
 +
 
 +
 
 +
 
 +
=== *nix ===
  
 
== Copyright ==
 
== Copyright ==

Revision as of 09:22, 1 September 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 across DLL / shared library boundaries.
  • On *nix systems default symbol visibility is changed to hidden, and only with export marked symbols are visible.

Rationale

Turning export into an attribute

Currently the export protection level is the highest level of visibility. This however does not allow exporting protected members. Exported protected members is neccessary sometimes though. Consider the following example.

module sharedLib;

class Base
{
  protected final void DoSomething() { ... }

  public void func()
  {
    DoSomething();
  }
}


module executable;
import sharedLib;

class Derived
{
  protected final void DoSomethingAdditional() { ... }

  public ovveride void func()
  {
    DoSomething();
    DoSomethingAdditional();
  }
}

In the above example 'DoSomething' should only be visible to derived classes but should still be exported from a shared library. This does not work with the current implementation of 'export'. Turning 'export' into an attribute will make this work.

Implicitly exporting compiler internal symbols of a module

Currently compiler internal symbols of modules are not exported at all. This leads to liner errors when linking against shared libraries on windows. By marking compiler internal symbols as 'export' as soon as there is a single exported symbol in the module will fix this problem.

export attribute inferrence

Currently export has to be specified in a lot of places to export all neccessary functions and data symbols. Export should be transitive in such a sense that it only needs to be specified once in a module to export all of its functions / data members including classes and their members / data symbols. Consider the following example:

module sharedLib:

export:

__gshared int g_Var; // should be exported

void globalFunc() { ... } // should be exported

class A // compiler internal members should be exported
{
  private:
    int m_a;

    static int s_b; // should not be exported

    void internalFunc() { ... } // should not be exported

  protected:
    void interalFunc2() { ... } // should be exported

  public:
    class Inner // compiler internal members should be exported
    {
       static s_inner; // should be exported

       void innerMethod() { ... } // should be exported
    }

    void method() { ... } // should be exported
}

private class C // should not be exported
{
   public void method() { ... } // should not be exported
}

Access TLS variables

Currently it is not possible to acces TLS variables across shared library boundaries. This should be implemented. See implementation details.

Change symbol visibility on *nix systems

When building shared libraries on *nix systems all symbols are visible by default. This can lead to long loading time of shared libraries if they contain a large number of symbols. Also everything visible by deafult makes it hard to commit to a certain stable interface, as one has no control over the visible symbols.

Implementation Details

Windows

*nix

Copyright

This document has been placed in the Public Domain.