Dynamic D Library

[Jarrett Billingsley]

On Thu, Jul 16, 2009 at 10:44 AM, Jarrett
Billingsley<jarrett.billingsley at gmail.com> wrote:
> 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.
>

Furthermore, even if you *could* somehow work out a solution whereby
regular DLLs could be made and transparently loaded, there's an even
more major problem: the way exception handling is implemented on
Windows means that exceptions cannot be thrown out of DLLs into the
host.  It's just not something that can be solved, from what I
understand.