digitalmars.D.learn - How can I hide implementation details when make a library
- Daniel Kozak (8/8) Sep 25 2012 Hello,
- Jacob Carlborg (4/11) Sep 25 2012 You can manually create .di files just as you would with C/C++.
- Daniel Kozak (5/22) Sep 25 2012 Yes, it works. Thanks a lot.
- Jacob Carlborg (12/15) Sep 25 2012 The source code is included to be able to inline the functions. It's
- Jonathan M Davis (19/23) Sep 25 2012 A number of features do not work if not all of the source is available. ...
- Daniel Kozak (3/41) Sep 26 2012 Thanks for explanation.
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
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
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
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 declarationsThe 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
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 declarationsA 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
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:Thanks for explanation.Yes, it works. Thanks a lot. However I still dont get it, why dmd generates all sources instead of just public symbols and functions declarationsA 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 26 2012