Hello,


I try to make for example some small library called libX. In C/C++ I can make libX.h(pp) and libX.c(xx), where libX.h will contain only interface for implementation from libX.c.

How can I achive this in D2?

When I trak dmd -o- -op -H libX.d it will generate libX.di, but this file always contains all source code from libX.d. It just strip comments.

On 2012-09-25 13:39, Daniel Kozak wrote:
> Hello,
>
>
> I try to make for example some small library called libX. In C/C++ I can
> make libX.h(pp) and libX.c(xx), where libX.h will contain only interface
> for implementation from libX.c.
>
> How can I achive this in D2?
>
> When I trak dmd -o- -op -H libX.d it will generate libX.di, but this
> file always contains all source code from libX.d. It just strip comments.

You can manually create .di files just as you would with C/C++.

-- 
/Jacob Carlborg

Yes, it works. Thanks a lot.

However I still dont get it, why dmd generates all sources instead of just public symbols and functions declarations


On Tuesday, 25 September 2012 at 11:39:56 UTC, Jacob Carlborg wrote:
> On 2012-09-25 13:39, Daniel Kozak wrote:
>> Hello,
>>
>>
>> I try to make for example some small library called libX. In C/C++ I can
>> make libX.h(pp) and libX.c(xx), where libX.h will contain only interface
>> for implementation from libX.c.
>>
>> How can I achive this in D2?
>>
>> When I trak dmd -o- -op -H libX.d it will generate libX.di, but this
>> file always contains all source code from libX.d. It just strip comments.
>
> You can manually create .di files just as you would with C/C++.

On 2012-09-25 13:58, Daniel Kozak wrote:
> Yes, it works. Thanks a lot.
>
> However I still dont get it, why dmd generates all sources instead of
> just public symbols and functions declarations

The source code is included to be able to inline the functions. It's probably has something to do with the metaprogramming features in D, like, static-if, string and template mixin, auto and several other features. There has been some discussion about this in the newsgroup which you should be able to find.

One problem in particular is with "auto". For some reason the compiler won't do a full semantic analyze when generating import files, resulting it cannot resolve "auto". You also need to have the source code of a function to resolve return types declared as "auto".

-- 
/Jacob Carlborg

On Tuesday, September 25, 2012 13:58:00 Daniel Kozak wrote:
> Yes, it works. Thanks a lot.
> 
> However I still dont get it, why dmd generates all sources instead of just public symbols and functions declarations

A number of features do not work if not all of the source is available. In particular, functions can't be inlined if the compiler doesn't have their source, and any function which is used at compile time (using CTFE - compile time function evaluation) needs its full source and the source of every function that it calls. So, in general, it's pretty crippling to not have the full source available. Also, templates tend to be used quite heavily in D, and because templates aren't actually instantiated until they're used, their entire source must be in the .di file regardless, making it so that you _can't_ hide their code (C++ has exactly the same issue). So, in general, .di files don't make a lot of sense.

But if all that anyone is doing is calling the functions at runtime, and it doesn't matter that they're not inlinable, and you don't need any of them to be templated (or it's okay for the few that are templated to have their full source in the .di file), then you can strip out the function bodies in .di files, and that _can_ be useful if you really need that, but pretty much no one's going to do that unless they have to (or just don't understand what they lose by doing so).

- Jonathan M Davis

On Tuesday, 25 September 2012 at 17:54:39 UTC, Jonathan M Davis wrote:
> On Tuesday, September 25, 2012 13:58:00 Daniel Kozak wrote:
>> Yes, it works. Thanks a lot.
>> 
>> However I still dont get it, why dmd generates all sources
>> instead of just public symbols and functions declarations
>
> A number of features do not work if not all of the source is available. In
> particular, functions can't be inlined if the compiler doesn't have their
> source, and any function which is used at compile time (using CTFE - compile
> time function evaluation) needs its full source and the source of every
> function that it calls. So, in general, it's pretty crippling to not have the
> full source available. Also, templates tend to be used quite heavily in D, and
> because templates aren't actually instantiated until they're used, their
> entire source must be in the .di file regardless, making it so that you _can't_
> hide their code (C++ has exactly the same issue). So, in general, .di files
> don't make a lot of sense.
>
> But if all that anyone is doing is calling the functions at runtime, and it
> doesn't matter that they're not inlinable, and you don't need any of them to
> be templated (or it's okay for the few that are templated to have their full
> source in the .di file), then you can strip out the function bodies in .di
> files, and that _can_ be useful if you really need that, but pretty much no
> one's going to do that unless they have to (or just don't understand what they
> lose by doing so).
>
> - Jonathan M Davis


Thanks for explanation.