Dynamic D Library

[Jarrett Billingsley]

On Thu, Jul 16, 2009 at 2:12 AM, teo<teo.ubuntu at yahoo.com> wrote:
> One major problem is the D's inability to create dynamic libraries. D is a great language, but without that ability it can only be used for small programs, tools, etc. and never in production.

For one, I question your logic that without dynamic libraries, D can
never be more than a hobby language.  For two, there is *no problem*
with creating D libraries on any platform other than Windows, and it
is entirely through Windows' fault that it has the problems it does
with DLLs.

> However “If the library contains a D
>  runtime it will be integrated with the current runtime.
> ” Is this really needed?

What that means is that any static constructors in the library need to
be run and the GC in the library's runtime needs to be hooked up to
the host's GC (otherwise you'd have two GCs in one app, not fun).

> If the intention is to replace C/C++ some day, why not just provide a dynamic D library? (like in this project: http://www.dsource.org/projects/ddl/) It can contain only compiled D code accompanied with meta-data like platform, version, etc. and be used only by D programs. No runtime is needed within the DDL. When the DDL is loaded it will be managed by the same GC which manages the program itself. Even Phobos can be a DDL.
>
> Maybe I am missing something and that's why I would like to hear your opinion.

You're missing something :)  DDL doesn't require you to have a D
runtime in the shared library because unlike DLLs, DDLs can have
unresolved externals.  That's the main issue: DLLs must have performed
all their symbol resolution at link-time, and cannot automatically
load symbols out of the host.  So, you end up with all the runtime
duplicated in the DLL.  DDLs, as well as shared libraries on _every
other platform_, allow you to have unresolved externals in the shared
library which are linked at *load-time*, so that there is one runtime,
which is in the host, which all the shared libraries use.