Le 11/04/2012 19:03, Johannes Pfau a écrit :
Am Wed, 11 Apr 2012 11:56:00 +0200
schrieb deadalnix<[email protected]>:
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.
