Re: Export ?

[Maxim Fomin]

On Tuesday, 10 April 2012 at 17:34:25 UTC, deadalnix wrote:
For consistency across systems, I suggest that, unless marked 
as exported, symbols are hidden by default. This have other 
advantages as shown in the linked page about gcc. For D, it 
also mean that the linker will have all information to finalize 
all methods that are not marked as export, and I think this is 
something we want to mitigate the cost of all methods virtual 
by default.

The site says : « Ex­port means that any code out­side the 
ex­e­cutable can ac­cess the mem­ber. Ex­port is 
anal­o­gous to ex­port­ing de­f­i­n­i­tions from a 
DLL. » so, clearly it is not saying anything about posix 
systems (you'll not find many DLL on those) and not what D 
compiler does.

It means that export comes as an extra qualifier, and not as an 
alternative to public/private/protected/package . You can be 
both export AND public/private/protected/package .

This already have been discussed here, but no conclusion has 
been made.

TDPL is opposite about this issue. It clearly states that it is a 
top of permissive access. Currently dmd rejects both export and 
for example private, or public. Whether library files are 
compiled separately or not (because of the D module design) an 
importer always see an imported module as a source code and it 
doesn't care whether linker hides symbol or not.

If you order compiler and linker to hide any symbol which is not 
exported (with export keyword) following problem occures:

lib.d:
export class Export {}
public class Public {}
...

main.d:
import lib;

void main()
{
        auto e = new Export();
        auto pub = new Public();
        e.test();
        pub.test(); // am i compiled as a library or part of executable?
}