Compiler as dll

[grauzone]

Daniel Keep wrote:
> 
> grauzone wrote:
>> John Reimer wrote:
>>> ddl does not work for memory sharing like normal dll's, where multiple
>>> applications have access to a single dll at runtime.  It appears that
>>> such support would be quite difficult to implement and moves in the
>>> direction of operating system features.
>> Couldn't this be achieved by simply mmap()-ing the file contents into
>> memory? mmap() normally shared the memory pages with other processes.
> 
> I'm sure users of DDL would love for you to submit a patch. :)
> 
>> Of course, this wouldn't work if the code both isn't position
>> independent, and needs to be relocated to a different base address. But
>> that's also the case with operating system supported dynamic shared
>> objects.
>>
>>> It does do runtime linking, however, which is extremely useful for
>>> certain situations... specifically any sort of application that needs
>>> a plugin architecture for D (ie.. it can link with libraries and
>>> object files at runtime) that is gc and exception friendly.  
>> I never understood why this is needed. Can't they simply compile the
>> plugins into the main program?
> 
> A plugin architecture, by definition, is to let third parties add code
> to your application.  This rather precludes being able to simply link it in.

But why go through the trouble of doing dynamic linking? You still can 
have a plugin architecture without dynamic linking.

>> When it's a commercial program, the DLL plugin approach probably
>> wouldn't work anyway: in order to enable others to compile plugins, you
>> would need to expose your internal "headers" (D modules). Note that
>> unlike in languages like C/C++, this would cause internal modules to be
>> exposed too, even if they are not strictly needed. What would you do to
>> avoid this? Maintain a separate set of import modules?
> 
> As Alexander Pánek said; you can just use .di files, which the compiler
> can create from existing .d modules.

See my reply to his posting.

> Heck, you can just use regular .d modules and stub out the
> implementations.  There's no reason why you'd need to release your code
> to third parties.

Sure, if you like tedious work. And you have to be extremely careful. 
Writing an extern(C) based interface will be not much more work, but the 
result will be much more robust, and give you some extra advantages, 
like enabling other languages to link to it.

> Templates are a different matter, but then C++ has the same problem.
> Whether or not you want to release your templates as part of the SDK
> really depends on what they are.  Templates + interfaces make a good pair.

Sure. Bytecode based languages like C# still can export compiled 
generics, though. Of course, they are not as flexible as D or C++ templates.

>> I think a purely extern(C) based interface would be better in these cases.
>>
>> In fact, if you rely on the D ABI for dynamic linking, you'll probably
>> have the same trouble as with C++ dynamic linking. For example, BeOS had
>> to go through this to make sure their C++ based API maintains ABI
>> compatibility:
>>
>> http://homepage.corbina.net/~maloff/holy-wars/fbc.html
>>
>> I'm not sure if the D ABI improves the situation. At any rate, it
>> doesn't sound like a good idea.
> 
> There's some interesting problems at that article that maybe we should
> ask Walter about.  For one, being able to control virtual function
> ordering is an interesting idea.
> 
> But by and large, these are the same problems you'll get with ANY ABI.
> If the size of a struct changes in a C ABI, you're hosed just as bad as
> if the size of a struct in D, or the fields of a class.

I'm not sure, but I think you could solve many of these problems by 
using linker symbols instead of compile time constants for sizes and 
field offsets. Still doesn't work in D, because CTFE still needs them as 
real compile time constants. And it'd probably be less efficient.

>   -- Daniel