"Export" logic does not work on variables

Benjamin Thaut code at benjamin-thaut.de
Sun Aug 25 05:17:14 PDT 2013


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


More information about the Digitalmars-d mailing list