www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How can I hide implementation details when make a library

reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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.
Sep 25 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 25 2012
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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++.
Sep 25 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Sep 25 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Sep 25 2012
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
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.
Sep 26 2012