On Monday, 3 October 2016 at 17:45:55 UTC, Jonathan M Davis wrote:
The import statement just tells the D compiler to pull in
declarations for the symbols that it needs from those modules.
It doesn't actually compile those modules. You still have to
give them to the compiler (either all together or separately to
generate .o/.obj files) in order to actually compile them. And
anything that's not D (like a C/C++ library) still needs to be
linked in just like it would be in C/C++.
In C/C++, #including is not enough to compile everything into
your code unless everything is in the header files (which it
rarely is). For the files in your project, you have to compile
every .c/.cpp file to generate the .o or .obj files that the
linker then links into your program, and for the 3rd party
stuff that's in a library you need to link in the library.
Simply #including doesn't actually bring something like curl or
gtk into your program. You also have to link it when generating
your executable.
It's basically the same thing with D. Every .d file in your
project needs to be compiled so that it gets linked into your
executable, and if you want to use 3rd party stuff, you have to
link in the libraries just like you would with C/C++. The
separation is perhaps a bit less clear in D, because you
usually just use .d files for everything, whereas C/C++ have .h
and .c/.cpp as separate files. D does have .di files for the
cases where you need to hide your code, but they don't get used
often. But when you do use a .di file, that's what gets
imported rather than the .d file which contains the actual
definitions, so in that case, the separation is clearer.
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.
A big thank-you to all repliers for making things clear :D
