output minimal .di files?
Alex Rønne Petersen
xtzgzorex at gmail.com
Mon Jan 16 12:32:57 PST 2012
On 16-01-2012 21:08, H. S. Teoh wrote:
> On Mon, Jan 16, 2012 at 11:38:15AM -0800, Adam Wilson wrote:
>> 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.
> But if you remove function bodies from inline-able functions, then your
> library loses out on potential optimization by the compiler. Besides,
> all your templates are still world-readable, which, depending on what
> your library is, may pretty much comprise your entire library anyway.
> To *truly* have separation of API from implementation, interface files
> shouldn't even have templated functions. It should list ONLY public
> declarations, no private members, no function bodies, no template
> bodies, etc.. All function bodies, including inline functions, template
> bodies, private members, etc., should be in a binary format readable
> only by the compiler.
> One way to implement this is to store template/inline function bodies
> inside the precompiled object files as extra info that the compiler
> loads in order to be able to expand templates/inline functions, compute
> the size of structs/classes (because private members are not listed in
> the API file), and so on. How this is feasible to implement, I can't
> say; some platforms may not allow arbitrary data inside object files, so
> the compiler may not be able to store the requisite information in them.
I... don't think the error messages from expanding raw object code would
be very pleasant to read, if you used a template incorrectly...
More information about the Digitalmars-d-learn