On Tuesday, 19 April 2016 at 08:57:21 UTC, Jonathan M Davis wrote:
On Tuesday, April 19, 2016 07:58:19 Satoshi via Digitalmars-d
wrote:
Why cannot be exported every public/protected method by
default? When I am creating so/dll I want to export almost
everything. Methods what I dont want to export I should mark
as private or package or package(nameOfRootPackage).
From the standpoint of simplicity, that's definitely nicer.
With C/C++ and
Linux, the default is that all symbols in a shared library are
visible, whereas on Windows, on those which are explicitly
exported are visible, and I always found having to deal with
building on a Windows a royal pain - especially when what I had
done just worked on Linux.
However, there are some good arguments for not just exporting
everything - particularly with regards to compilation
efficiency. It's not that uncommon for a library to have a
public API that everyone should see and use while having a
bunch of functions that are used only internally and really
shouldn't be exposed to users of the library. To some extent,
package can be used to hide those, but the larger the library,
the harder that gets. And if a library is very deep (i.e. its
functions do a lot for you), then you're fairly quickly going
to end up with functionality that ideally would be hidden, and
putting everything in one module or package isn't always
reasonable. As it is Phobos has std.internal which is
theoretically not supposed to be used outside of Phobos, but
it's completely importable and usable by any code using Phobos.
Having code like that restricted by export could be desirable.
I expect that hiding symbols which aren't public would
certainly help a great deal in avoiding having a lot of
unnecessary symbols in a compiled library, but it doesn't
completely solve the problem. And when discussions on export
have come up, some of the folks who are particularly
knowledgeable on the subject have been _very_ much in favor of
using export to restrict what is and isn't visible in the
generated library rather than relying on public. They'll have
to chime in to provide good details though. The main issue that
I recall is the desire/need to reduce the number of symbols in
order to make compiling/linking more efficient.
- Jonathan M Davis
But when I create two versions of the same library (shared and
static one). Public symbols will be accessible through the static
library but inaccessible through the shared library.
Library is a one big package and marking symbols as
package(MyLib) is same as mark them as public in shared object.
e.g. I have MyLib and TestApp
MyLib
- math.d
- foo.d
- bar/test.d
TestApp
- main.d
or subpackages like
rikarin.core;
rikarin.appkit;
rikarin.base;
rikarin.backend;
etc.
I can easily create internal methods through the package(rikarin)
definition. And package symbols shouldn't be exported.
