Export ?

[deadalnix]

Le 11/04/2012 19:03, Johannes Pfau a écrit :
> Am Wed, 11 Apr 2012 11:56:00 +0200
> schrieb deadalnix<deadalnix at gmail.com>:
>>
>> It isn't a misfeature. The link explain why it is interesting :
>>    - It improves load time of DSO.
>>    - Allow more optimizations.
>>    - Reduce DSO size by 5% to 20% for C++. Considering how long
>> mangling are in D, probably more for us.
>>    - Reduce name collision (this one poorly apply to D, because the
>> module system handle that quite nicely).
>>
>> Additionally, it allow automatic finalization for non exported
>> methods in D.
>>
>
> This explains why symbol visibility is useful. But do we really need
> 'export'? Are there cases where public = export, private/package =
> 'not exported' wouldn't work?
>
> When do you actually need 'not-exported' and public? And would export
> private/export package be valid?
>

public and export aren't the same thing.

If public qualify how the symbol can be acessed by code, export qualify 
how the symbol can be linked. An exported symbol can be linked at 
runtime, but a non exported symbol cannot.

If public = export, then drawback expressed above will occur. If 
protected = not exported, then you cannot extends a class from you main 
application in a DSO (or the other way around). You usually don't want that.