Just to get it righ: this means GC will be in dl tool so people that complain about exe size and gc bloat will be happy about it?
Roald Ribe Wrote: > Justin Johansson wrote: > > Rainer Schuetze wrote: > > > >> 5. To share gc-collected objects between different DLLs, a common > >> phobos-DLL seems necessary. Extracting the GC into a separate DLL and > >> using the proxy-mechanism to attach any other client-DLL to it seems > >> feasable, but are there other things that need to be shared between > >> different phobos-instances? What about exception-handling? > >> > > > > Sounds like you have the right idea; that sounds similar to the > > way Microsoft does it with MFC DLL's. If I recall correctly, > > when MFC applications are DLL based, you link with a common C runtime > > DLL as well. This way all memory allocations and frees are handled > > by the common C runtime DLL (i.e. single point of responsibility). > > Presumably a similar regime for D and the GC would be necessary. > > Not only MFC. Plain C and C++ programs as well. This is why most MS- > Windows based compiled languages comes with two versions of the > runtime lib, one for static link and one for dynamic link (DLL). > > If not, there will always be problems with DLL's in that language > sharing file handles, memory, sockets, threads and so on. > > The flip side of the coin is "DLL hell" (use Google). It is less of > a problem in newer versions of MS-Windows than it used to be, but > necessary to consider when supporting older platforms. > > The Linux/BSD/unix side I know less about, but since they have a > common location for shared libs and support multiple versions of > the same lib (AFAIK) the problems are less there. > > Roald
