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

41–50 of 269 posts

Re: What to do with C++ modules?

#41

Post by tsimionescu »

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…

Use a feature that doesn't really work, after so many years, hoping compilers will actually make it work if people use it - seems like a disastrous plan. People have tried to use modules, and have generally found that they fail, and have dumped them.

It's unlikely at this point modules in their current form will ever be anything but a legacy feature in C++. Maybe someday a new implementation will arise, just like noexcept replaced the failed "throws" declaration.

Re: What to do with C++ modules?

#42

Post by spacechild1 »

holowoodman wrote: post #2

Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.

How did you get that impression? There are many areas where C++ is still the first choice. Also, "legacy maintenance stuff" is quite an understatement, given how much of our world is powered by C++: browser engines, language runtimes, game engines, video editors, DAWs, automation software, medical equipment, flight control software, etc.

If you think that "the world seems to have moved on to Rust", I would recommend to look at the job listings. For example, devjobs.de: Rust: 61, C++: 1546. That's 1:25. Maybe in other countries there are more Rust jobs?

Re: What to do with C++ modules?

#43

Post by gary_0 »

WalterBright wrote: post #5

Back in the 90s, I implemented precompiled headers for my C++ compiler (Symantec C++). They were very much like modules. There were two modes of operation: 1. all the .h files were compiled, and emitted as a binary that could be rolled in all at once 2. each .h file created its own precompiled header. Sounds like modules, right? Anyhow, I learned a lot, mostly that without semantic improvements to C++, while it made…

I can't think of a C++ project I've worked on that didn't rely on being able to include C headers and have things usually just work. Are there ways of banning C macros from "modular" C++ without breaking that? (Many would find it unacceptable if you had to go through every C dependency and write/generate some sort of wrapper.)

Re: What to do with C++ modules?

#44

Post by tandr »

InCom-0 wrote: post #25
holowoodman wrote: post #2

Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.

Have a look at any serious job postings. C++ jobs outnumber Rust jobs somewhere around 50:1. Internet hype meets actual industry reality :-).

Or could it be (or to be a bit of devil's advocate) that Rust projects require only 2% (1/50) of manpower, comparing the same project using C++?

Re: What to do with C++ modules?

#45

Post by WalterBright »

Calavar wrote: post #20
WalterBright wrote: post #5

Back in the 90s, I implemented precompiled headers for my C++ compiler (Symantec C++). They were very much like modules. There were two modes of operation: 1. all the .h files were compiled, and emitted as a binary that could be rolled in all at once 2. each .h file created its own precompiled header. Sounds like modules, right? Anyhow, I learned a lot, mostly that without semantic improvements to C++, while it made…

Did anyone reach out to you for input during the modules standardization process? D seems like the most obvious prior art, but the modules standardization process seems like it was especially cursed

Nobody from C++ reached out to me for the modules.

Herb Sutter, Andrei Alexandrescu and myself once submitted an official proposal for "static if" for C++, based on the huge success it has had in D. We received a vehement rejection. It demotivated me from submitting further proposals. ("static if" replaces the C preprocessor #if/#ifdef/#ifndef constructions.)

C++ has gone on to adopt many features of D, but usually with modifications that make them less useful.

Re: What to do with C++ modules?

#46

Post by WalterBright »

fooker wrote: post #12
WalterBright wrote: post #5

Back in the 90s, I implemented precompiled headers for my C++ compiler (Symantec C++). They were very much like modules. There were two modes of operation: 1. all the .h files were compiled, and emitted as a binary that could be rolled in all at once 2. each .h file created its own precompiled header. Sounds like modules, right? Anyhow, I learned a lot, mostly that without semantic improvements to C++, while it made…

What has to change in C++ templates for this to work? It seems particularly tricky to define a template in a module and then instantiate it or specialize it somewhere else.

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.

Re: What to do with C++ modules?

#47

Post by WalterBright »

emtel wrote: post #33

I did C++ for over 10 years, and now have been doing rust for about 4. On the whole, I like rust much better, but I really miss header files. Modules are horrible for build times. If you change an implementation (i.e something that would not normally involve editing a header) the amount of rebuilding that happens is crazy, compared to any C++ project that was set up with a minimal amount of care.

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

Re: What to do with C++ modules?

#49

Post by TylerGlaiel »

All that the C++ committee needed to do was just introduce "import" as "this is the same as include except no context can leak into it".

Would have been dirt simple to migrate existing codebases over to using it (find and replace include with import, mostly), and initial implementations of it on the compiler side could have been nearly identical to what's already there, while offering some easy space for optimizing it significantly.

Instead they wanted to make an entirely new thing that's impossible to retrofit into existing projects so its basically DOA

Re: What to do with C++ modules?

#50

Post by reactordev »

TylerGlaiel wrote: post #49

All that the C++ committee needed to do was just introduce "import" as "this is the same as include except no context can leak into it". Would have been dirt simple to migrate existing codebases over to using it (find and replace include with import, mostly), and initial implementations of it on the compiler side could have been nearly identical to what's already there, while offering some easy space for optimizing i…

That could be said of every additional c++ feature since c++0x.

The committee has taken backwards compatibility, backwards - refusing to introduce any nuance change in favor of a completely new modus operandi. Which never jives with existing ways of doing things because no one wants to fix that 20 year old codebase.

Post reply on HN