www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "Export" logic does not work on variables

reply Benjamin Thaut <code benjamin-thaut.de> writes:
The logic behind the export keyword seems to be flawed. As explained in 
this ticket:

http://d.puremagic.com/issues/show_bug.cgi?id=9816

For declarations export means __declspec(dllimport) and for definitions 
__declspec(dllexport).

export void foo();   // this treated as import
export void foo() {} // this treated as export

For global variables to be an export you need an initializer.

export __gshared int bar;     // this treated as import
export __gshared int bar = 0; // this treated as export

This makes using the export keyword very cumbersome as you always have 
to pay attention to initialize variables so they actually get treated as 
export and also you most likely will always need a .d file and a .di 
file for the same module to make it work. Can't we think of a different 
logic for the export keyword so you only have to write the module once 
and it works in both cases?

I could also only find a single line in the language documentation 
describing export which doesn't really help understanding it:

"Export means that any code outside the executable can access the 
member. Export is analogous to exporting definitions from a DLL. "

So whats a "member"? A class, a function, a member variable? What about 
global variables? Vtables? TypeInfo objects? RTInfo!T instances? From my 
experiences the only thing that does actually work is exporting 
functions, everything else is broken (see the bug ticket mentioned above).

Now that we have shared library support on linux platforms it would be 
nice if we could get it on Windows too. I'm currently looking into 
exporting variables from dlls but the lack of documentation on the topic 
makes it hard. Any insights, links, references to books or other 
materials are welcome.

Kind Regards
Benjamin Thaut
Aug 25 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/25/13, Benjamin Thaut <code benjamin-thaut.de> wrote:

 This makes using the export keyword very cumbersome as you always have
 to pay attention to initialize variables so they actually get treated as
 export.


Yeah I dislike this behavior as well, I think it might have been
carried over from C/C++ (?).

Also look at the confusing extern keyword semantics:
http://dlang.org/declaration.html#extern
Aug 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-25 15:18, Andrej Mitrovic wrote:


 Also look at the confusing extern keyword semantics:
 http://dlang.org/declaration.html#extern


What's confusing about the extern keyword?

-- 
/Jacob Carlborg
Aug 25 2013
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/25/13, Jacob Carlborg <doob me.com> wrote:

 Also look at the confusing extern keyword semantics:
 http://dlang.org/declaration.html#extern


 What's confusing about the extern keyword?


`extern` => storage class, `extern(NAME)` => linkage attribute. Using
the same keyword for two things is confusing.
Aug 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-25 14:17, Benjamin Thaut wrote:


 export __gshared int bar;     // this treated as import


I would have guessed that required extern as well to be import.

-- 
/Jacob Carlborg
Aug 25 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 25.08.2013 15:51, schrieb Jacob Carlborg:

 On 2013-08-25 14:17, Benjamin Thaut wrote:


 export __gshared int bar;     // this treated as import


 I would have guessed that required extern as well to be import.


But as D does not have a Preprocessor and version statements can not be 
used to replace the usual API macros used in C/C++ we need export to 
work in a way so that it means both import and export at the same time.

-- 
Kind Regards
Benjamin Thaut
Aug 25 2013