Jump to page: 1 26  
Page
Thread overview
Building C++ modules
Aug 09
Dukc
Aug 09
Ethan
Aug 09
Dukc
6 days ago
Walter Bright
5 days ago
Atila Neves
6 days ago
matheus
6 days ago
Adam D. Ruppe
5 days ago
Atila Neves
5 days ago
Exil
5 days ago
H. S. Teoh
5 days ago
Exil
5 days ago
H. S. Teoh
5 days ago
Stefan Koch
5 days ago
H. S. Teoh
4 days ago
Exil
4 days ago
H. S. Teoh
5 days ago
matheus
5 days ago
Adam D. Ruppe
5 days ago
matheus
5 days ago
bachmeier
5 days ago
Atila Neves
4 days ago
SashaGreat
2 days ago
Jacob Carlborg
4 days ago
Kagamin
4 days ago
Atila Neves
4 days ago
matheus
Aug 10
MrSmith
Aug 10
Dukc
Re: Reggae [was Building C++ modules]
6 days ago
Jacob Carlborg
6 days ago
H. S. Teoh
6 days ago
Walter Bright
6 days ago
Jacob Carlborg
6 days ago
H. S. Teoh
6 days ago
Walter Bright
6 days ago
H. S. Teoh
6 days ago
Walter Bright
4 days ago
Kagamin
August 07
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
August 08
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



August 09
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!


August 09
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?


August 09
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.
August 09
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.
August 09
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.


August 09
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



August 09
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.


August 10
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



« First   ‹ Prev
1 2 3 4 5 6