output minimal .di files?

Jonathan M Davis jmdavisProg at gmx.com
Mon Jan 16 00:25:21 PST 2012

On Monday, January 16, 2012 00:14:02 Adam Wilson wrote:
> I'm assuming that your goal is to build either or static or dynamic
> libraries?
> If that is the case than you can assume that CTFE and inlining will not
> work anyways. This is an inherent limitation of libraries and not D. What
> D currently does is assume that you want everything to work, and spits out
> your implementation code symbol-for-symbol. The only thing I've found that
> D ever strips out of DI files is unittests. I have written a patch for DMD
> that strips out non-template class/function implementations with the
> understanding that CTFE and inlining will no longer work. Templated
> functions and classes retain their implementations, this is in line with
> the way C++ operates. Unfortunately my patch isn't well tested yet so I
> haven't opened the pull required to get it included into the main line DMD
> code. But it's a available from my Git account
> [https://LightBender@github.com/LightBender/dmd.git] if you don't mind
> building DMD yourself.

Inlining and CTFE should work just fine as long as everything that you're 
trying to inline or use with CTFE is in the .di file. Sure, whatever you strip 
out of the .di file won't work with CTFE or inlining, but inlining and CTFE 
should work just fine with dynamic libraries, exactly like if you had stuff in 
the .h file in C++. You just have to be willing to have it in the .di file.

And you _still_ get the benefits of a dynamic library, since the symbols don't 
get duplicated between programs which share the library. It's just that you 
still have to recompile everything that it's in the .di file, so less can have 
its symbol hidden (for Windows anyway - there is no symbol hiding in shared 
libraries in linux). But you can definitely using inlining and CTFE with 
dynamic libraries.

- Jonathan m Davis

More information about the Digitalmars-d-learn mailing list