On Mon, 16 Jan 2012 00:25:21 -0800, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
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://lightben...@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
I would say the main reason for using .h/.di files in libraries is that
the library designer does not want his implementation public viewable. And
in D, unlike C/C++, .di files are pretty much exclusive to the concept of
libraries. I'd say that, based on how many questions are raised about .di
files, almost no one expects the current behavior, I certainly didn't,
hence my patch. The DI generation patch currently implements the C++
paradigm, where templated function implementations are publicly viewable,
but non-templated function implementations are not. I feel that this
paradigm, being the currently accepted convention, is the best path for D
to take.
--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
