On Thu, Jul 16, 2009 at 10:44 AM, Jarrett Billingsley<[email protected]> wrote: > On Thu, Jul 16, 2009 at 2:12 AM, teo<[email protected]> 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.
