Jarrett Billingsley wrote:
On Thu, Jul 16, 2009 at 4:44 PM, teo<teo.ubu...@yahoo.com> wrote:
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.
Well, let us assume that you can create dynamic libraries in D and you need to
include in each of them Phobos (later maybe just the D Runtime). What is the
benefit of that? Can you imagine all your nice dynamic libraries (DLLs, SOs,
etc.) written in D and all of them including a huge “payload”? Wouldn't it be
better just a simple library only containing the stuff you need?
I don't think you're getting it.
ON WINDOWS, DLLs are not allowed to have unresolved externals. So if
you create a DLL in D, yes, Phobos will be linked in. THERE IS
NOTHING THAT CAN BE DONE ABOUT THAT. It's a limitation on the way
DLLs work.
ON EVERY OTHER OPERATING SYSTEM (Linux, Unix, OSX, *whatever*), shared
libraries CAN have unresolved externals, so Phobos *does not* have to
be included in the shared libraries. Shared libraries ALREADY work
the way you expect them to on every OS besides Windows.
The ONLY way to solve the problem with DLLs on Windows is to not use
DLLs. Java solves it by not using any platform-dependent libraries,
instead using its own .class files. This is *exactly* what DDL does.
So, I'm not sure what you see as the problem here. DDL works fine on
Windows. Use it.
You learn something new everyday. That's pretty cool.
Incidentally, this is exactly the kind of stuff that I'd love to see
built right into DRuntime or Phobos.
I don't have a use for it right now (cuz my project is simple enough not
to need dynamic loading), but in the future, I'd be reluctant to use DDL
because:
1) Dynamic loading is something that, to me, seems completely
fundamental to the runtime system, and I'd be hesitant to trust a
third-party library to keep up-to-date with the current compiler &
standard library.
2) DDL isn't even really a third-party library. It's more like a
fourth-party, since (I assume) it really requires the h3r3tic patch to
work correctly.
Building this kind of functionality into the standard library would make
those issues irrelevant.
These kinds of issues are the ones that excite me the most and are the
things I'd like to see D pay the most attention to. From my perspective,
features of the runtime and standard library are often much more
compelling than new language features.
--benji
