Hi!

Jussi Pakkanen (from Meson build system fame) has written this article[1] about compiling C++ code that uses modules. I think it's worth a read.

Antonio

[1] https://nibblestew.blogspot.com/2019/08/building-c-modules-take-n1.html

On Wed, 2019-08-07 at 16:04 +0000, Antonio Corbi via Digitalmars-d wrote:
> Hi!
> 
> Jussi Pakkanen (from Meson build system fame) has written this article[1] about compiling C++ code that uses modules. I think it's worth a read.
> 
> Antonio
> 
> [1] https://nibblestew.blogspot.com/2019/08/building-c-modules-take-n1.html

So if C++ has this dependency problem why doesn't D, Go, or Rust?

Chapel developers decided to allow for separate compilation but tend to advocate who source at once compilation. This is cool as you can do global optimisation in a way not possible with separate compilation.

If one of D's plus points is fast parsing and compilation, perhaps whole source at once compilation should be a good thing?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, 8 August 2019 at 10:10:30 UTC, Russel Winder wrote:
> On Wed, 2019-08-07 at 16:04 +0000, Antonio Corbi via Digitalmars-d wrote:
>> Hi!
>> 
>> Jussi Pakkanen (from Meson build system fame) has written this article[1] about compiling C++ code that uses modules. I think it's worth a read.
>> 
>> Antonio
>> 
>> [1] https://nibblestew.blogspot.com/2019/08/building-c-modules-take-n1.html
>
> So if C++ has this dependency problem why doesn't D, Go, or Rust?

I think that one of the reasons is that D, Go, and Rust (and Java, and...) map module names to file names, so other than -I flags or equivalent there's no need to figure out where the modules are actually located.

C++, to preserve support for platforms that don't have a hierarchical filesystem (I have no idea what they are or why anyone cares about them), decided to punt on how to find modules and leaves it up to the implementation.

The other difference is that despite having modules, C++20 still has the equivalent of module headers and module implementations.

I read a whole blog post explaining C++ modules once. I shook my head throughout and can't believe what they've gone with. I've also forgotten most of it, probably due to my brain protecting itself lest I go mad.


> If one of D's plus points is fast parsing and compilation, perhaps whole source at once compilation should be a good thing?

I don't think it is. Fast is relative, and it's death by a thousand cuts for me at the moment. And this despite the fact that I use reggae as much as I can, which means I wait less than most other D programmers on average to get a compiled binary!

On Friday, 9 August 2019 at 08:37:25 UTC, Atila Neves wrote:
> The other difference is that despite having modules, C++20 still has the equivalent of module headers and module implementations.

Don't we have those too? .hd files.

> Fast is relative, and it's death by a thousand cuts for me at the moment. And this despite the fact that I use reggae as much as I can, which means I wait less than most other D programmers on average to get a compiled binary!

I remember that you did blog that 1.5 seconds compile time or something like that is already frustatingly long for you.

What do you think if the effect of compile time there, to programmer? I had to use Dub with a --combined build back at Windows, and while it sure was a lot slower than a bare D compiler, it was still faster than the main part of my project written in C#. Even then, I found the compile time (haven't measured, but probably like 20 seconds for debug build if both D and C# files were changed) only mildly annoying. So I'm interested, are virtually-instant compiles something one has to experience to understand their benefit?

On Friday, 9 August 2019 at 09:22:12 UTC, Dukc wrote:
> On Friday, 9 August 2019 at 08:37:25 UTC, Atila Neves wrote:
>> The other difference is that despite having modules, C++20 still has the equivalent of module headers and module implementations.
>
> Don't we have those too? .hd files.

.di files are usually auto-generated, not needed, and AFAIK not that used.

> I remember that you did blog that 1.5 seconds compile time or something like that is already frustatingly long for you.

Indeed.

> What do you think if the effect of compile time there, to programmer?

From experience, it makes me work much slower if I don't get results in less than 100ms. If I'm not mistaken, IBM did a study on this that I read once but never managed to find again about how much faster people worked on short feedback cycles.

> I had to use Dub with a --combined build back at Windows,

Doing pretty much anything on Windows will mean it'll be slower.

> and while it sure was a lot slower than a bare D compiler, it was still faster than the main part of my project written in C#. Even then, I found the compile time (haven't measured, but probably like 20 seconds for debug build if both D and C# files were changed) only mildly annoying.

That's why I said fast is relative. What's mildly annoying for you makes my brain slow to a crawl, never mind the frustration and desire to headbutt the wall repeatedly.

> So I'm interested, are virtually-instant compiles something one has to experience to understand their benefit?

Maybe? There's the IBM research I talked about, but I can't remember the details or the general applicability.

On Friday, 9 August 2019 at 13:17:02 UTC, Atila Neves wrote:
> .di files are usually auto-generated, not needed, and AFAIK not that used.

They're needed. At least, the idea of them is needed.

Right now, it's just a glorified implementation stripper. Gets rid of everything between {} that aren't aggregate/enum definitions, and leaves the slow and expensive mixins there to be recompiled every. single. time. they're. imported.

.di files need to be redefined to represent a module after mixins have resolved.

On Friday, 9 August 2019 at 08:37:25 UTC, Atila Neves wrote:
> C++, to preserve support for platforms that don't have a hierarchical filesystem (I have no idea what they are or why anyone cares about them), decided to punt on how to find modules and leaves it up to the implementation.
>

This was done to support mainframe operaring systems,  I think. As far as I can tell, z/OS (formerly OS/360) doesn't have a hierarchical file system in the classic sense. Objects there have a name with different segments/fields, but at least a few of them have semantics that the operating susten cares about.

This is also one of the reasons why the committee didn't standardize #pragma once in favor of a #once [unique id].

> The other difference is that despite having modules, C++20 still has the equivalent of module headers and module implementations.
>
> I read a whole blog post explaining C++ modules once. I shook my head throughout and can't believe what they've gone with. I've also forgotten most of it, probably due to my brain protecting itself lest I go mad.

Reading up on C++ modules leaves the impression that the ball was dropped so hard that it left a massive crater on impact. I have tries ti read up on them several times and I still haven't figured out how you aee supposed to use them.

On Fri, 2019-08-09 at 08:37 +0000, Atila Neves via Digitalmars-d wrote: […]
> I don't think it is. Fast is relative, and it's death by a thousand cuts for me at the moment. And this despite the fact that I use reggae as much as I can, which means I wait less than most other D programmers on average to get a compiled binary!

Is there any chance of getting Reggae into D-Apt or better still the standard Debian Sid repository along with ldc2, GtkD, and GStreamerD, so it can be a standard install for anyone using Debian or Ubuntu and so get some real traction in the D build market?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 9 August 2019 at 13:17:02 UTC, Atila Neves wrote:
> From experience, it makes me work much slower if I don't get results in less than 100ms.

Wow! I guess my work habits are wayyyyy too lax :D.

> Doing pretty much anything on Windows will mean it'll be slower.

The C# compilation feels about as fast, perhaps because I use its compiler via Wine. But DUB on Linux is just a lightning strike (from my perspective). And that's even if run on the NTFS-using Windows partition of my hard drive! And OpenSUSE does not seem to periodically choke on running some dubious background process, unlike Windows. So, I mostly agree.

On Fri, 2019-08-09 at 13:17 +0000, Atila Neves via Digitalmars-d wrote:
> 
[…]
>  From experience, it makes me work much slower if I don't get
> results in less than 100ms. If I'm not mistaken, IBM did a study
> on this that I read once but never managed to find again about
> how much faster people worked on short feedback cycles.
> 
[…]

Most people in the world couldn't tell the difference between 100ms and 200ms. But this leads to a whole off-theme discussion about psychology, reaction times, and "won't wait" times.

Also of course: https://www.xkcd.com/303/

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk