== Quote from Don (nos...@nospam.com)'s article > Tim M wrote: > > > >> No way! On Windows, bud is much better. dsss can't build dlls, for > >> example, which is a blocker for me. It also seems to be based around > >> the flawed concept that you have a small number of build configurations. > > > > > > GC'd memory and DLL just don't go well together. I use C++ for my dlls > > but D for the main apps now. It's just about ok for single threaded. > > Most of the time I have to write dlls for existsing apps that I have no > > source for so thats why I can't use ddl either. > I go the other way around -- app is in C++, DLLs are in D. The API is > entirely extern(C).
I think the extern (C) approach is safest, but I may as well mention that DMD 2.0 / Phobos does provide limited support for a D app that uses objects defined in a D DLL. The Runtime.loadLibrary() call will override the DLLs GC to use the app's GC instead, so passing objects across the DLL boundary becomes possible. I'm personally not terribly fond of this idea because it has a bunch of issues, but it *does* exist in the DMD distro today. Oh, I suppose I should mention that multithreaded DLLs (ie DLLs that spawn their own threads) are not supported at the moment. This can change if necessary, but it will mean yet more complex machinery in some parts of the runtime that are already pretty dicey. Truth be told I'd rather just do away with the whole idea altogether. Sean