Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What to do with C++ modules?

nibblestew.blogspot.com

Post reply on HN
Print view View original

151–160 of 269 posts

Re: What to do with C++ modules?

#151

Post by saagarjha »

pizlonator wrote: post #84

The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. The pre processor and linker, as derided as they are, allow for scaling of software size to extremes not possible with supposedly superior languages’ supposedly superior module systems. Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that…

I don't see anything that makes this impossible. In fact I think this is just a result of nobody making a project of that scale in those languages yet, rather than it being fundamentally impossible.

Re: What to do with C++ modules?

#153

Post by uncircle »

nitwit005 wrote: post #92
pizlonator wrote: post #84

The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. The pre processor and linker, as derided as they are, allow for scaling of software size to extremes not possible with supposedly superior languages’ supposedly superior module systems. Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that…

The Linux kernel is tens of millions of lines, so I'm rather doubtful at the existence of this OS over a billion lines.

> I'm rather doubtful at the existence of this OS over a billion lines

Someone somewhere is trying to vibe code the entirety of the Linux kernel using Copilot.

Re: What to do with C++ modules?

#154

Post by zbendefy »

StephenHerlihyy wrote: post #35

Modules provide more than just speed. Compile time benefits are great and the article is right about build-time bloat being the bane of every developer. But modules serve a deeper purpose. Explicit sub-unit encapsulation. True isolation. No more weird forward declarations, endlessly nested ifdef guards, or insane header dependency graphs. Things just exist as they are separate, atomic, deterministic and reliable. Mod…

Thing is (correct.me if Im wrong), that if you use modules, all of your code need to use modules (e.g. you cant have mixed #include and import ; in your project). Which rules out a lot of 3rd party code you might want to depend on.

Re: What to do with C++ modules?

#155

Post by WalterBright »

Gibbon1 wrote: post #108
WalterBright wrote: post #46

Earlier quoted context omitted.

In order to make things work smoothly, the module has to have its own namespace, and a namespace that is closed. D also has an `alias` feature, where you can do things like: alias Q = abc.T; where from then on, `abc.T` can be referred to simply as `Q`. This also eliminates a large chunk of purpose behind the preprocessor.

I've really wanted that in C for a long time. It seems like a very trivial thing as well.

Yeah, it's actually easy to implement, too.

It replaces the preprocesser:

    #define Q abc.T
with hygiene. Once you get used to it, it has all kinds of nice uses.

Re: What to do with C++ modules?

#156

Post by dzdt »

feelamee wrote: post #60
WalterBright wrote: post #47

Earlier quoted context omitted.

D modules are very fast. Many of our customers rely on D being way faster than C++ to compile.

I often hear about a lot of advantages of D. So I don't understand why it is so unpopular. Probably I need to give it a chance, but I'm unsure that I will find a real job with the D stack.

Most languages that have made it big have been the primary language for a platform that made it big, and it is really the features of the platform more than those of the language that have driven that.

Re: What to do with C++ modules?

#157

Post by tialaramex »

ghosty141 wrote: post #109
fooker wrote: post #16

Earlier quoted context omitted.

optional is heavily used in new codebases. variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use. Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.

> variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. Thats the fantastic thing about c++, you can already write an easy to use match, but they just chose not to include that in the stdlib but rather want you write that yourself. Example: match(foo, [](Foo&) { }, [&](Bar& bar) { }, [&](const auto& mode) { // catch all }); Also opti…

The try! macro was deprecated in 2019 so, almost six years ago. And even before formal deprecation the word try is now a keyword and so you'd need to use r#try! to say you want the obsolete macro not the keyword.

Re: What to do with C++ modules?

#159

Post by tialaramex »

fooker wrote: post #119
ReflectedImage wrote: post #95

Earlier quoted context omitted.

Rust is basically the wanted fixes to C++ that C++ itself could never adopt for legacy reasons. So I'm afraid no by definition C++ can't adopt Rust's ideas because Rust's ideas were originally impossible C++ ideas.

> C++ itself could never adopt for legacy reasons. I agree with your point except for the 'never' qualifier. It was certainly true when Rust was born. C++ has proven the 'never' part wrong multiple times. I think, by 2030, the only thing that C++ would lack that Rust has right now is the unified toolchain/packaging ecosystem because people are not going to settle that debate. Everything else is well on its way to be…

Concepts is a particularly hilarious example because what you got in C++ 20 is Bjarne's "Concepts Lite". Bjarne worked quite hard to get rid of the ideas and people behind the much more powerful C++ 0x Concepts, which resembles Rust's trait feature, and then it took a decade to land his worse alternative. That actually is a microcosmic survey of the problem with the language.

Re: What to do with C++ modules?

#160

Post by imtringued »

motorest wrote: post #97
modeless wrote: post #18

The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well:…

> The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc Tools like ccache have been around for over two decades, and all you need to do to onboard them is to install the executable and set an environment flag. What value d…

From my perspective there is a pretty big difference between a persistent compiler daemon and a simple cache that constantly restarts the compiler over and over again.
Post reply on HN