http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #19 from Martin Nowak <[email protected]> 2013-08-29 15:05:57 PDT --- (In reply to comment #18) > - when does export mean dllimport and when dllexport. Newsgroup discussion > brought up that we could enable dllimport/dllexport per module (including all > submodules) via a command line switch. There are some problems with the current implementation. export void foo() {} // definition => dllexport export void foo(); // declaration => dllimport export int a = 0; // definition => dllexport export int a; // declaration => dllimport // fails because it's actually a definition export extern int a; // declaration => dllimport It would be great if we could avoid extra .di headers. > - do we want a export all public symbols feature (discussion on the newsgroup > brought up that c++ is trying to move away from this, maybe we should too) Please let's try to go into the other direction on Unix too. You can find more about the reasoning here. http://gcc.gnu.org/wiki/Visibility http://people.redhat.com/drepper/dsohowto.pdf > - Should exporting of entire classes / structs be possible? E.g. marking a > class es export, exports its vtable, typeinfo, all protected / public > functions, > static members, etc. Yes, because there is no way to annotate compiler generated data. Once again please stay away from abusing protection for export because it creates too many problems for future language extensions, e.g. maintaining private symbols for ABI compatibility, module definitions in multiple files/objects, partial classes. Linking and symbol protection are fundamentally different concepts and we should offer orthogonal control. > - Which informations about modules need to be exported? Will they be > automatically exported as soon as the module has a single exported function / > class / variable? Yes, it's hidden compiler data and you might need to link against the ModuleInfo and some other symbols. > > > Well, the question is, whether we can annotate symbols with "export" and > > still > > create static libraries. > > At the moment: no. But we should create a solution where this very case will > work. Proposed solution. 'export' is always a no-op unless you specifiy > otherwise using a command line switch to the compiler. That sounds like a reasonable solution when we can't do better. Also see the alias discussion on the newsgroup http://forum.dlang.org/post/[email protected]. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
