On Wednesday, 31 May 2023 at 18:56:02 UTC, H. S. Teoh wrote:
On Wed, May 31, 2023 at 06:43:52PM +0000, Cecil Ward via
Digitalmars-d-learn wrote:
Is there an explanation of how D’s ‘import’ works somewhere?
I’m trying to understand the comparison with the inclusion of
.h files, similarities if any and differences with the process.
Unlike C's #include, `import` does NOT paste the contents of
the imported file into the context of `import`, like #include
would do. Instead, it causes the compiler to load and parse the
imported file, placing the parsed symbols into a separate
symbol table dedicated for that module (in D, a file == a
module). These symbols are then pulled into the local symbol
table so that they become available to code containing the
import declaration.
(There's a variation, `static import`, that does the same thing
except the last step of pulling symbols into the local symbol
table. So the symbols will not "pollute" the current namespace,
but are still accessible via their fully-qualified name (FQN),
i.e., by the form `pkg.mod.mysymbol`, for a symbol `mysymbol`
defined in the module `pkg.mod`, which in turn is a module
under the package `pkg`.)
For more information:
https://tour.dlang.org/tour/en/basics/imports-and-modules
https://dlang.org/spec/module.html
T
Thank you so very much for the links and for your generous help.
Some C compilers used to have a thing called ‘precompiled
headers’, potential source of trouble and ai always felt uneasy
about it rightly or wrongly.
It’s great that D has got rid of header file includes though,
they were ridiculously painful. I used to use the automake
feature that was built into the JPI C compiler at work which took
care of all the .h dependencies so you no longer had to worry
about it. And you only loaded the compiler from disk and started
it up once as it stayed in memory handling all the C parts of a
make.
