On Saturday, 29 September 2012 at 16:09:14 UTC, Jacob Carlborg
wrote:
There's no point in doing that. But what I'm saying is if you
know beforehand the libraries you will use you can get quite
far with static libraries.
There are plenty of cases where you have to use a dynamically
loaded lib even if you know before hand what will be loaded. I
think you understand this if I read your posts correctly.
In my case I have a pre-existing C++ app that is designed to load
user defined C++ plugins. I wanted to interface D to one of my
own C++ plugins, but I apparently cannot do it reliably because
of initialization issues with the GC and possibly some other
obscure items.
If I can figure out what needs to be done to resolve the problem
in enough detail, then maybe I can hack the runtime source and
roll out a solution.
The GC always seems to pop up as a source of problems. For long
term solution, the GC should be made 100% optional (in practice
as opposed to in theory), the standard library ought to be made
to work with or wothout a GC (or simply without), and the GC
itself should be easily replaceable with alternate versions. I
think this idea has already been discussed elsewhere, and is on
the TODO list (I hope!).
--rt
