www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How does =?UTF-8?B?ROKAmXMg4oCYaW1wb3J04oCZ?= work?

reply Cecil Ward <cecil cecilward.com> writes:
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.
May 31 2023
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
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

-- 
People who are more than casually interested in computers should have at least
some idea of what the underlying hardware is like. Otherwise the programs they
write will be pretty weird. -- D. Knuth
May 31 2023
parent Cecil Ward <cecil cecilward.com> writes:
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.
May 31 2023
prev sibling next sibling parent reply Cecil Ward <cecil cecilward.com> writes:
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward 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.


I have another question if I may, what do we do about getting 
makefiles right given that we have imports ?
May 31 2023
next sibling parent reply Andrew <andrewlalisofficial gmail.com> writes:
On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:

 I have another question if I may, what do we do about getting 
 makefiles right given that we have imports ?


Others can correct me if I'm wrong, but I don't think that it is 
a priority for D to be specially compatible with makefiles in any 
way beyond the whole separation of compilation and linking.
Jun 02 2023
parent rempas <rempas tutanota.com> writes:
On Friday, 2 June 2023 at 11:27:31 UTC, Andrew wrote:

 Others can correct me if I'm wrong, but I don't think that it 
 is a priority for D to be specially compatible with makefiles 
 in any way beyond the whole separation of compilation and 
 linking.


If he was talking about using GNU Make as a build system for D, 
then you are right! We have [dub](https://dub.pm/index.html) for 
that exact reason!
Jun 02 2023
prev sibling next sibling parent reply rempas <rempas tutanota.com> writes:
On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:

 I have another question if I may, what do we do about getting 
 makefiles right given that we have imports ?


What do you mean with that? Give some more info please!
Jun 02 2023
parent reply Cecil Ward <cecil cecilward.com> writes:
On Friday, 2 June 2023 at 12:07:09 UTC, rempas wrote:

 On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:

 I have another question if I may, what do we do about getting 
 makefiles right given that we have imports ?


 What do you mean with that? Give some more info please!


I was thinking about the situation in C where I have a rule in a 
make file that lists the .h files as well as the .c all as 
dependencies in creating an object file.
Jun 07 2023
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 6/7/23 21:17, Cecil Ward wrote:


 I was thinking about the situation in C where I have a rule in a make
 file that lists the .h files as well as the .c all as dependencies in
 creating an object file.


dmd's -makedeps command line switch should be helpful there. (I did not 
use it.)

Ali
Jun 07 2023
parent reply Cecil Ward <cecil cecilward.com> writes:
On Thursday, 8 June 2023 at 05:11:04 UTC, Ali Çehreli wrote:

 On 6/7/23 21:17, Cecil Ward wrote:


 I was thinking about the situation in C where I have a rule


 in a make

 file that lists the .h files as well as the .c all as


 dependencies in

 creating an object file.


 dmd's -makedeps command line switch should be helpful there. (I 
 did not use it.)

 Ali


I wasn’t intending to use DMD, rather ldc if possible or GDC 
because of their excellent optimisation, in which DMD seems 
lacking, is that fair? (Have only briefly looked at dmd+x86 and 
haven’t given DMD’s back end a fair trial.)
Jun 18 2023
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote:

 On Thursday, 8 June 2023 at 05:11:04 UTC, Ali Çehreli wrote:

 dmd's -makedeps command line switch should be helpful there. 
 (I did not use it.)

 Ali


 I wasn’t intending to use DMD, rather ldc if possible or GDC 
 because of their excellent optimisation, in which DMD seems 
 lacking, is that fair? (Have only briefly looked at dmd+x86 and 
 haven’t given DMD’s back end a fair trial.)


LDC has the same feature with its --makedeps flag.
Jun 18 2023
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn 
wrote:

 I wasn’t intending to use DMD, rather ldc if possible or GDC
 because of their excellent optimisation, in which DMD seems
 lacking, is that fair? (Have only briefly looked at dmd+x86 and
 haven’t given DMD’s back end a fair trial.)


In general, dmd is fantastic for its fast compilation speed. So, it works
really well for developing whatever software you're working on (whereas ldc
and gdc are typically going to be slower at compiling). And depending on
what you're doing, the code is plenty fast. However, if you want to maximize
the efficiency of your code, then you definitely want to be building the
binaries that you actually use or release with ldc or gdc.

- Jonathan M Davis
Jun 18 2023
parent reply Cecil Ward <cecil cecilward.com> writes:
On Sunday, 18 June 2023 at 21:51:14 UTC, Jonathan M Davis wrote:

 On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via 
 Digitalmars-d-learn wrote:

 I wasn’t intending to use DMD, rather ldc if possible or GDC 
 because of their excellent optimisation, in which DMD seems 
 lacking, is that fair? (Have only briefly looked at dmd+x86 
 and haven’t given DMD’s back end a fair trial.)


 In general, dmd is fantastic for its fast compilation speed. 
 So, it works really well for developing whatever software 
 you're working on (whereas ldc and gdc are typically going to 
 be slower at compiling). And depending on what you're doing, 
 the code is plenty fast. However, if you want to maximize the 
 efficiency of your code, then you definitely want to be 
 building the binaries that you actually use or release with ldc 
 or gdc.

 - Jonathan M Davis


Good point. I’m used to slow compilers on fast machines and 
compiling gives me an excuse for more coffee and possibly fruity 
buns. I’m incredibly impressed with LDC, GDC slightly less so, as 
it sometimes calls runtime library routines where Ldc doesn’t. 
Like in things to do with arrays, for one example.

I hate calls to runtime library routines unless they are really 
substantial, mind you many calls to a modest-sized routine can 
get you a hotter cache, and even micro-op cache, and keep the 
whole code size down so as to improve cache overload or even 
pollution.
Jun 20 2023
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 6/20/23 08:09, Cecil Ward wrote:


 I’m used to slow compilers on fast machines and compiling
 gives me an excuse for more coffee and possibly fruity buns.


Yes, all of us in past projects accepted C++'s slowness. We did get 
coffee, etc. One of my current colleagues regularly plays solitaire when 
waiting for C++ compilations. Not only it's not a professional sight, 
but C++ is proving to be a professional mistake.

Nobody should suffer from such context switches. I have a hunch, without 
any backing research data, that C++'s contribution to humanity may be 
net negative.

D is nothing like that: My turnaround is a few seconds: Write, compile, 
run, see the effect... I use only dmd partly because of laziness: it 
just works. Although I take full advantage D's low level powers, my 
programs have mostly been I/O bound with huge files, so dmd's less-than 
ideal optimization powers are hidden because most threads are waiting 
for file system I/O.

Aside: std.parallelism and std.concurrency have been very helpful.

Ali
Jun 20 2023
parent Cecil Ward <cecil cecilward.com> writes:
On Tuesday, 20 June 2023 at 17:56:27 UTC, Ali Çehreli wrote:

 On 6/20/23 08:09, Cecil Ward wrote:


 I’m used to slow compilers on fast machines and compiling
 gives me an excuse for more coffee and possibly fruity buns.


 Yes, all of us in past projects accepted C++'s slowness. We did 
 get coffee, etc. One of my current colleagues regularly plays 
 solitaire when waiting for C++ compilations. Not only it's not 
 a professional sight, but C++ is proving to be a professional 
 mistake.

 Nobody should suffer from such context switches. I have a 
 hunch, without any backing research data, that C++'s 
 contribution to humanity may be net negative.

 D is nothing like that: My turnaround is a few seconds: Write, 
 compile, run, see the effect... I use only dmd partly because 
 of laziness: it just works. Although I take full advantage D's 
 low level powers, my programs have mostly been I/O bound with 
 huge files, so dmd's less-than ideal optimization powers are 
 hidden because most threads are waiting for file system I/O.

 Aside: std.parallelism and std.concurrency have been very 
 helpful.

 Ali


In the 1980s on our VAX 11/750, compile jobs were batch jobs 
placed in a queue. Half hour waits were not unknown. A build of 
the new o/s we were working on took around 40 mins on a 33 MHz 
386 Dell PC (later a 486!) iirc. So time for patisserie even. But 
in oractice you simply got on with other jobs, like writing new 
code that was not yet integrated, code reviews, all sorts of 
things.
Jun 24 2023
prev sibling next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sun, Jun 18, 2023 at 03:51:14PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:

 On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn 
 wrote:

 I wasn’t intending to use DMD, rather ldc if possible or GDC
 because of their excellent optimisation, in which DMD seems
 lacking, is that fair? (Have only briefly looked at dmd+x86 and
 haven’t given DMD’s back end a fair trial.)




My experience with D for the past decade or so has consistently shown
that executables produced by LDC or GDC generally run about 40% faster
than those produced by DMD. Especially with CPU-intensive computations.
This is just the hard fact.

Of course, for some applications like shell-script replacements (which,
incidentally, D is really good at -- once your script passes the level
of complexity beyond which writing a shell script just becomes
unmanageable), the difference doesn't really matter, and I'd use DMD
just for faster compile times.

The one thing the DMD backend is really good at, is compiling stuff
*really* fast. LDC has been catching up in this department, but
currently DMD still wins the fast compilation time race, by quite a lot.
So it's very useful for fast turnaround when you're coding.  But for
release builds, LDC and GDC are your ticket.



 In general, dmd is fantastic for its fast compilation speed. So, it
 works really well for developing whatever software you're working on
 (whereas ldc and gdc are typically going to be slower at compiling).
 And depending on what you're doing, the code is plenty fast. However,
 if you want to maximize the efficiency of your code, then you
 definitely want to be building the binaries that you actually use or
 release with ldc or gdc.


[...]

Yeah, LDC/GDC are really good at producing optimized executables, but
they do take a long time to do it. (Probably 'cos it's a hard problem!)
So for development -- DMD.  For final release build -- GDC/LDC.


T

-- 
If it tastes good, it's probably bad for you.
Jun 18 2023
prev sibling parent rempas <rempas tutanota.com> writes:
On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote:

 I wasn’t intending to use DMD, rather ldc if possible or GDC 
 because of their excellent optimisation, in which DMD seems 
 lacking, is that fair? (Have only briefly looked at dmd+x86 and 
 haven’t given DMD’s back end a fair trial.)


Other than the execution runtime, one other very important 
problem with DMD that wasn't refered is that is only support x86 
and x86_64. LDC and GDC support LLVM's and GCC's architectures 
respectively.
Jun 19 2023
prev sibling parent reply rempas <rempas tutanota.com> writes:
On Thursday, 8 June 2023 at 04:17:20 UTC, Cecil Ward wrote:

 I was thinking about the situation in C where I have a rule in 
 a make file that lists the .h files as well as the .c all as 
 dependencies in creating an object file.


I don't think I'm aware of what you mean with "lists .h and .c 
files". Could you provide a small makefile that does that so I 
can run and examine?
Jun 18 2023
parent reply Cecil Ward <cecil cecilward.com> writes:
On Sunday, 18 June 2023 at 17:34:51 UTC, rempas wrote:

 On Thursday, 8 June 2023 at 04:17:20 UTC, Cecil Ward wrote:

 I was thinking about the situation in C where I have a rule in 
 a make file that lists the .h files as well as the .c all as 
 dependencies in creating an object file.


 I don't think I'm aware of what you mean with "lists .h and .c 
 files". Could you provide a small makefile that does that so I 
 can run and examine?


target.obj: target.c include1.h include2.h cc.exe
     cc target.c

and you either have to pray that you have kept the list of .h 
files that are mentioned inside target.c and other .h files 
referenced recursively from within these .h files etc. I listed 
the compiler as a dependency too, and I should really have a 
pseudo-target somehow that depends on the nature of the command 
line because changing the command line affects the generated 
code. If you have an automaking compiler that will generate the 
list of .h files then that’s so, so much safer.
Jun 18 2023
parent reply rempas <rempas tutanota.com> writes:
On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:

 target.obj: target.c include1.h include2.h cc.exe
     cc target.c

 and you either have to pray that you have kept the list of .h 
 files that are mentioned inside target.c and other .h files 
 referenced recursively from within these .h files etc. I listed 
 the compiler as a dependency too, and I should really have a 
 pseudo-target somehow that depends on the nature of the command 
 line because changing the command line affects the generated 
 code. If you have an automaking compiler that will generate the 
 list of .h files then that’s so, so much safer.


First of all, If we are talking about C files, D can import and 
compile them so you don't even need a Makefile! Now, if you need 
to compile C++ files and then either link or create a library 
(and link with it from the D project), then you can just run Dub 
in the end of the job in your make file! You can then have a 
variable called `DUB_FLAGS` in your Makefile and this is where 
the arguments that will be passed for the Dub will be. Will this 
be good enough for you?
Jun 19 2023
parent reply Cecil Ward <cecil cecilward.com> writes:
On Monday, 19 June 2023 at 08:46:31 UTC, rempas wrote:

 On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:

 target.obj: target.c include1.h include2.h cc.exe
     cc target.c

 and you either have to pray that you have kept the list of .h 
 files that are mentioned inside target.c and other .h files 
 referenced recursively from within these .h files etc. I 
 listed the compiler as a dependency too, and I should really 
 have a pseudo-target somehow that depends on the nature of the 
 command line because changing the command line affects the 
 generated code. If you have an automaking compiler that will 
 generate the list of .h files then that’s so, so much safer.


 First of all, If we are talking about C files, D can import and 
 compile them so you don't even need a Makefile! Now, if you 
 need to compile C++ files and then either link or create a 
 library (and link with it from the D project), then you can 
 just run Dub in the end of the job in your make file! You can 
 then have a variable called `DUB_FLAGS` in your Makefile and 
 this is where the arguments that will be passed for the Dub 
 will be. Will this be good enough for you?


If I have sources to all the library routines, not libraries or 
.obj files. I am simply completely ignorant about the D tools 
including DUB, so off to do some reading. I’ve just been seeing 
how good LDC and GDC are, and the answer is extremely, especially 
LDC, which perhaps has a slight edge in code generation quality. 
I haven’t looked at AAarch64 code yet, only AMD64. Very impressed 
with all the work!
Jun 19 2023
parent reply rempas <rempas tutanota.com> writes:
On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote:

 If I have sources to all the library routines, not libraries or 
 .obj files. I am simply completely ignorant about the D tools 
 including DUB, so off to do some reading. I’ve just been seeing 
 how good LDC and GDC are, and the answer is extremely, 
 especially LDC, which perhaps has a slight edge in code 
 generation quality. I haven’t looked at AAarch64 code yet, only 
 AMD64. Very impressed with all the work!


Of course, DMD uses it's own custom backend so it's only fair to 
not expect for it to have the same runtime performance and 
optimizations as the other two compilers than use LLVM and GCC. 
If you only use x86_64, DMD will be amazing for your debug cycles!
Jun 19 2023
parent Cecil Ward <cecil cecilward.com> writes:
On Monday, 19 June 2023 at 16:24:03 UTC, rempas wrote:

 On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote:

 If I have sources to all the library routines, not libraries 
 or .obj files. I am simply completely ignorant about the D 
 tools including DUB, so off to do some reading. I’ve just been 
 seeing how good LDC and GDC are, and the answer is extremely, 
 especially LDC, which perhaps has a slight edge in code 
 generation quality. I haven’t looked at AAarch64 code yet, 
 only AMD64. Very impressed with all the work!


 Of course, DMD uses it's own custom backend so it's only fair 
 to not expect for it to have the same runtime performance and 
 optimizations as the other two compilers than use LLVM and GCC. 
 If you only use x86_64, DMD will be amazing for your debug 
 cycles!


I’ve never used DMD. I don’t support that it will run on Aarch64. 
I’m running ldc on an ARM M2 Mac OSX. Also on x86-64 VMs at 
Godbolt.org but I must get access to an x86-64 box myself.
Jun 20 2023
prev sibling parent reply Dom DiSc <dominikus scherkl.de> writes:
On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:

 I have another question if I may, what do we do about getting 
 makefiles right given that we have imports ?


You can replace your whole makefile by calling the compiler with 
-I (not always, but if you don't do funny things in your 
makefile).
- This ability of the D compiler was just recently discovered 
(after -I was implemented for other reasons), but it relies on 
the fact that we have imports.
Jun 03 2023
parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 3 June 2023 at 09:04:35 UTC, Dom DiSc wrote:

 You can replace your whole makefile by calling the compiler 
 with -I (not always, but if you don't do funny things in your 
 makefile).


That would be `-i`.


 - This ability of the D compiler was just recently discovered 
 (after -I was implemented for other reasons), but it relies on 
 the fact that we have imports.


Jonathan Marler implemented it in 2017 after a discussion in the 
forums.

https://github.com/dlang/dmd/pull/7099
Jun 03 2023
prev sibling next sibling parent rempas <rempas tutanota.com> writes:
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward 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.


I do wonder why no-one have linked the [Modules and 
libraries](https://ddili.org/ders/d.en/modules.html) section in 
the [Programming in D](https://ddili.org/ders/d.en/index.html) 
book! The book is outdated in some things (and this isn't with 
logic, I have found one of these cases myself) but for most 
things, it will be ok!
Jun 02 2023
prev sibling next sibling parent rempas <rempas tutanota.com> writes:
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward 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.


I do wonder why no-one have linked the [Modules and 
libraries](https://ddili.org/ders/d.en/modules.html) section in 
the [Programming in D](https://ddili.org/ders/d.en/index.html) 
book! The book is outdated in some things (and this isn't with 
logic, I have found one of these cases myself) but for most 
things, it will be ok!
Jun 02 2023
prev sibling parent rempas <rempas tutanota.com> writes:
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward 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.


I do wonder why no-one have linked the [Modules and 
libraries](https://ddili.org/ders/d.en/modules.html) section in 
the [Programming in D](https://ddili.org/ders/d.en/index.html) 
book! The book is outdated in some things (and this isn't with 
logic, I have found one of these cases myself) but for most 
things, it will be ok!
Jun 18 2023