On 10/03/2016 07:19 PM, Chalix wrote:
> On Monday, 3 October 2016 at 13:51:28 UTC, Mike Parker wrote:
>> // wrapfoo.d
>> import foo;  // import the foo module from above
>>
>> void myFunc(string s)
>> {
>>     import std.string : toStringz;
>>     my_func(s.toStringz());
>> }
>
> Thank you for the example, Mike!
>
> And thanks to all others who support me with their answers! I didn't
> expect so much answers, the D community seems to be very helpful :)
>
> But there still is one thing, which I don't get:
>
> If I "import foo;" in my project, it will be compiled alongside. So
> there is no need for an extra library. Same should be for wrapfoo.d. If
> I "import wrapfoo;", I should just need the C-library "foo", and no
> D-library "food" right?
>
>
> To have a more practical example, I looked up the "header" of the GtkD
> gtk/Main.d file. There are functions exactly like you described:
>
>> public static void init(ref string[] argv)
>>     {
>>         int argc = cast(int)argv.length;
>>         char** outargv = Str.toStringzArray(argv);
>>
>>         gtk_init(&argc, &outargv);
>>
>>         argv = Str.toStringArray(outargv, argc);
>>     }
>
> This function wraps the C-like gtk_init function to a D init function.
> The gtk_init function is the function from the GTK+ library, which is
> loaded in the gtkc/gtk.d file:
>> Linker.link(gtk_init, "gtk_init", LIBRARY.GTK);
> Linker and link are defined in the gtkc/Loader.d
>
> So, why is it not enough just to "import gtk.Main"? What kind of code is
> inside the gtkd-3 library?

The gtkd-3 library contains for example the code you quoted above.

-- 
Mike Wey

On Monday, October 03, 2016 18:05:47 Chalix via Digitalmars-d-learn wrote:
> Ah great, now I understand it :)
> I thought, import and include would work the same way (taking all
> the code in the .h or .d file and pasting it into the other file).
> But if import extracts only the definitions, it is clear, that
> you have to link against the library, or to add all the .d files
> to your source code.

#include is a _very_ inefficient way to do things. It results in the same code being compiled over and over again, which is why pretty much every language post C/C++ has some sort of symbol import mechanism in attempt to compile everything only once. The way it works in D, you do end up with some amount of work being redone if you do incremental compilation, but even then, it minimizes how much it has to redo, and there are future improvements planned which will make it even better. There's a reason why D compiles so much faster than C/C++. :)

You should probably read this article by Walter on why C/C++ compilation is so slow:

http://www.digitalmars.com/articles/b54.html

It's quite enlightening - and horrifying.

- Jonathan M Davis