"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