12 ms·

What to do with C++ modules?

226 points by ingve 1y ago

holowoodman 1y ago
Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.
- boppo1 1y ago
  Sarcasm?
  - grg0 1y ago
    These comments only reflect the person's narrow view of the "world", along with a generous dosage of pride to state things about which one does not know. If every OS and driver and much of the backbone of society is "legacy maintenance stuff", then the statement is certainly correct.
- bukotron 1y ago
  Rust does not solve any problem existing in expecienced C++ developer career. You dont write modern C++ code in such a way memory leak or dangling pointer is possible at all) This is exactly WHY we dont see a rush movement of C++ developers to Rust throwing away everything for Rust. Rust is trying to solve problems that already not exist 99.9999% of time in modern C++ code style and standards. Also, some day C++ compilers or tooling will get its own Borrow Checker to completely forget about Rust - this will be done just for fun just to stop arguing with rust-fans :)
  - Philpax 1y ago
    Thinking that experience with C++'s many flaws will save you from running into them is delusional - just look at the number of CVEs in projects maintained by world-class C++ programmers. No amount of fallible human vigilance will stop you from forgetting the existence of a C++ quirk in the code you're rushing out before heading out for the night. Human oversight does not scale.
    - InCom-0 1y ago
      This is true ... except that Rust doesn't actually do any better in that regard. Rust solves 1 category of problems in a way that is not without its costs and other consequences. That is it. There are projects where this is very important, there are other projects where its virtually useless and the consequences just get in the way. It is not magic. It doesn't make anything actually 'safe'.
      - feelamee 1y ago
        sure, but don't forget that rust gives us also a nice tooling, functional syntax sugar like pattern matching, enums, monads; and other more or less useful things like explicit lifetimes
        InCom-0 1y ago
        Of course. This is kind of to be expected as it has the benefit of hindsight of 25+ years. It is infinitely easier to design better things with all the accumulated experience and know-how of what works and what doesn't under your belt. It would have been truly horrifying if that had not been the case. That being said, Rust is really about lifetimes. That's the big ticket selling point. My point above was that 1) it isn't a silver bullet and 2) it can be a real hindrance is many applications.
        flohofwoe 1y ago
        Tbh, only a mother can love Rust's syntax. It has even more "punctuation" than C++.
        sobakistodor 1y ago
        [dead]
      - dlahoda 1y ago
        what is this 1 category?
    - flohofwoe 1y ago
      When looking at the number of CVEs you'll also have to take the amount of code written in that language into account, a language which has no users also has no CVEs ;) I bet there's easily tens of thousands of times more C++ code than Rust code out there.
  - okanat 1y ago
    This is a very bad take. Rust does solve very real problems in C family languages. The number of people I met in Rust conferences that rewriting at least parts of rather big C++ codebases weren't small either. However, there is still big amount of code that is purely C++. Many of the older code bases still use C++03-style code too. Or they were written in the OOP design pattern golden era that requires huge reactors to adapt functional / modern code. Anything with Qt will not benefit from smart pointers. Even with Qt 6. Rust cannot solve these problems since the challenges are not purely technical but social too.
    - r_lee 1y ago
      I would say though that Rust has already had a profound social effect which has probably enabled those rewrites etc. It wasn't too long ago that it was brushed aside as noise yet now its gaining real momentum
- c0balt 1y ago
  I'm pretty sure a lot of fields would disagree with you. Last I checked game programming, OS development, embedded development and more were deeply invested in either C or more often C++, especially when RT tasks were involved or vendor-provided compilers are required. Rust just doesn't have close to the same type of adoption/support yet, especially when considering various embedded platforms.
  - holowoodman 1y ago
    There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
    - jonathrg 1y ago
      C++ is widely used in embedded. Most compilers support it. Usually you turn some things off (e.g. -fno-rtti, -fno-exceptions) and try to stick to some sane subset of the ++.
      - com2kid 1y ago
        C++ in embedded is basically C with classes. It is a nice simple language and often doesn't even include templates (or if it does they are very simple data structures that are not even heap allocated). C++ as C with classes is a pretty good language!
        deleted 1y ago
        [deleted]
    - grg0 1y ago
      Game engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.
- okanat 1y ago
  Newer stuff yes and it is great. However from basic rendering to browsers and the most complex applications (CAD, office software, finance, complex solvers like airline planning) are still in C++. Nobody will accept rewriting 35+ years of history. C++ code bases are really a lot longer-lived than any other software builds upon them. Hence we cannot drop it. Starting with C++17, I think committee has been doing the language a disservice and piled even more and more unintended complexity by rushing "improvements" like modules. I don't write C++ anymore due to my team switching to Rust and C only (for really old stuff and ABI). I am really scared of having to return though. Not because I am spoiled by Rust (I am though), but because catching up with all the silly things they added on top and how they interact with earlier stuff like iterators. C++ is a perfect language for unnecessary pitfalls. Newer standards just exploded this complexity.
  - jonathrg 1y ago
    I understand and empathize with your fear. C++23 added a type with 22 constructors (http://en.cppreference.com/w/cpp/utility/expected/expected.html http://en.cppreference.com/w/cpp/utility/expected/expected.h...), that ought to be enough to strike fear into anyone.
    - okanat 1y ago
      It already has a defect report too: https://cplusplus.github.io/LWG/issue3886 https://cplusplus.github.io/LWG/issue3886 .
    - samiv 1y ago
      Don't worry, C++25 will deprecate half of them and C++27 will remove them while adding 20 new ones just to be deprecated in C++30.
      - okanat 1y ago
        C++ standard and deprecation is a contradiction. They almost never deprecate things. Things always go more complex.
- whatevaa 1y ago
  Borrow checker is actually not very good solution for some domains. I remember reading that it would not be good for writing javascript VM like v8. Something about managing memory which lifetime actually depends on others, not rust code.
- fooker 1y ago
  C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.
  - Philpax 1y ago
    A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add, but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant` is, as far as I know, still limited, even in newer C++ code, because the ergonomics just aren't there.
    - fooker 1y ago
      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.
      - ghosty141 1y ago
        > 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 optional and expected are ergonomic nightmares since there is no "try!" macro like rust has. In general it lacks the infrastructure that is needed to make these types nice to use. It also clashes with other concepts like RAII where you kinda have to use exceptions when it comes to ctors that may fail.
- diath 1y ago
  There are a number of areas in programming where I'd always choose C++ over Rust - gameplay programming, retained-mode GUI programming and interpreted programming languages to name a few have very complex circular memory models that are somewhat solvable with weak_ptrs or refs stored in member variables passed through constructors but would be absolutely obnoxious to deal with and get right with the borrow checker.
  - ozars 1y ago
    Rust has Arc and Weak that can be used for solving it in a similar way C++ does. The primary difference is forcing usage of Mutex to avoid a large class of data race issues IMHO, and that's what makes it harder to get right. Async in Rust is also more mature than C++ coroutines. So there's also that. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=02e9565e45119d0bdb9859544ad0d58c https://play.rust-lang.org/?version=nightly&mode=debug&editi...
    - MindSpunk 1y ago
      Arc/Weak can only get you so far. The problem I have with Rust in the mentioned domains (gameplay programming, retained GUI, interpreters) is what makes it so good, sharing xor mutability. If you're writing lots of multi-threaded code it's fantastic. If your problem domain is like the ones mentioned it hurts you. These are all highly non-parallel problems. They don't gain much from being parallel, and because Rust imposes 'restrict' semantics on even single threaded code you end up making it much harder to write code in these domains. This has been my experience with Rust. Shared mutability is safe on a single thread without 'restrict' on all your pointers, and Rust has limited options to opt into shared mutability (with lots of ergonomic caveats). Don't get me wrong though, I still think Rust is a great tool. It just has tradeoffs.
      - zozbot234 1y ago
        > Rust has limited options to opt into shared mutability The idiomatic Rust equivalent of a C non-restrict pointer is arguably &Cell<T>. The biggest problem with it is library code that takes &mut T when the likes of &Cell<T> might suffice (because potential aliasing does not affect the semantics of what that Rust code is doing), but this is an acknowledged problem and the Rust project will take pull req's that fix it where it occurs.
- InCom-0 1y ago
  Have a look at any serious job postings. C++ jobs outnumber Rust jobs somewhere around 50:1. Internet hype meets actual industry reality :-).
  - tandr 1y ago
    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++?
    - lyu07282 1y ago
      I couldn't even tell if you are joking. Rust is weird, its like a programming language people developed a parasocial relationship with. If a Twitch streamer was a programming language it would be Rust. Perhaps its just people being immature I don't know.
      - feelamee 1y ago
        > I couldn't even tell if you are joking I'm thinking the same about your comment :D
        lyu07282 1y ago
        It's a programming language with a fandom, isn't that odd? ^^
      - tandr 1y ago
        I was, but I guess adding /s at the end in these cases is a requirement nowadays...
    - Dylan16807 1y ago
      That's not devil's advocate, that's just being silly.
    - SkiFire13 1y ago
      Even if the basic idea might make sense there's no way the number if anywhere close to 1/50. Even 1/2 sounds unrealistic.
- spacechild1 1y ago
  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?
- flohofwoe 1y ago
  Rust isn't exactly famous for its fast build times. It's probably the only language that actually builds slower than C++, which is an impressive achievement on its own ;) And give Rust one or two more decades and it will be the same messy kitchen sink language as C++. If anything, Rust is speedrunning C++ history (with the notable exception of fixing static memory safety of course).
WalterBright 1y ago
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 compilation much faster, it was too sensitive to breakage. This experience was rolled into the design of D modules, which work like a champ. They were everything I wanted modules to be. In particular, The semantic meaning of the module is completely independent of wherever it is imported from. Anyhow, C++ is welcome to adopt the D design of modules. C++ would get modules that have 25 years of use, and are very satisfying. Yes, I do understand that the C preprocessor macros are a problem. My recommendation is, find language solutions to replace the preprocessor. C++ is most of the way there, just finish the job and relegate the preprocessor to the dustbin.
- fooker 1y ago
  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.
  - WalterBright 1y ago
    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.
    - fooker 1y ago
      Neat, closed namespaces sound great! C++ has adapted the ‘using’ keyword now to seem fairly similar to alias, but can’t completely subsume macros unfortunately.
      - 1y ago
nurettin 1y ago
If you avoid circular refs and forward declarations by writing hierarchical code, you won't really need modules. In my current project I'm 20+ headers in and still haven't had a circular ref. Just refactor all the commonly used code, decouple with callbacks and you have yourself a nice clean header only library that you can amalgamate and/or precompile.
- RossBencina 1y ago
  > If you avoid circular refs See the book "Large Scale C++ Software Design" by John Lakos for more detail in this direction.
modeless 1y ago
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 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: https://github.com/pizlonator/fil-c https://github.com/pizlonator/fil-c
- dgan 1y ago
  what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests
  - modeless 1y ago
    The catch is performance. It's not 200x slower though! 2x-4x is the actual range you can expect. There are many applications where that could be an acceptable tradeoff for achieving absolute memory safety of unmodified C/C++ code. But also consider that it's one guy's side project! If it was standardized and widely adopted I'm certain the performance penalty could be reduced with more effort on the implementation. And I'm also sure that for new C/C++ code that's aware of the performance characteristics of Fil-C that we could come up with ways to mitigate performance issues.
    - munificent 1y ago
      I mean, if I could accept a 2x-4x performance hit, then I wouldn't be using C++ in the first place. At that point, there are any of a number of other languages that are miles more pleasant to program in.
      - modeless 1y ago
forrestthewoods 1y ago
> modules should be killed and taken out of the standard. Yes. The C++ standard is an abomination that is both over-specified and wildly under-specified. Modules are simply never going to work en masse. It is a failed idea.
jeffbee 1y ago
Obligatory: https://arewemodulesyet.org/tools/ https://arewemodulesyet.org/tools/ Not great!
psyclobe 1y ago
Modules are unusable in real projects with real dependencies. Until that changes there’s no chance I’ll look at them.
- feelamee 1y ago
  how are modules related to dependencies in general? You can use your modules at the same time using dependencies via includes. And this works well.
  - psyclobe 1y ago
    Can't include _any_ header downstream if you import std, it is also unknown how you're gonna export and share modules across dependencies you have no indention of 'porting' to modules...
    - feelamee 1y ago
      why everyone is fixated around `import std`?? Its only one library. If you can't use `import std` this is not mean that you can't use modules... > it is also unknown how you're gonna export and share modules across dependencies you have no indention of 'porting' to modules... as a first step you can introduce modules only in private interfaces of your lib. This is also absolutely valid usage.. There is no solution to invent modules in such way that everyone just switch compiler flag and have fun. If you expect this, so...
emtel 1y ago
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.
- WalterBright 1y ago
  D modules are very fast. Many of our customers rely on D being way faster than C++ to compile.
  - feelamee 1y ago
    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.
    - WalterBright 1y ago
      Knowing D will make you a better programmer in other languages. For example, D pushes you to write better encapsulated modules, which is a transferable skill.
    - dzdt 1y ago
      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.
      - tialaramex 1y ago
        > Most languages that have made it big have been the primary language for a platform that made it big, I think you're going to want to define "made it big" and then make yourself some lists as this to me sounds like it doesn't have much explanatory power.
StephenHerlihyy 1y ago
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. Modules probably need a revision, and yes, adoption has been slow, but once you start using modules you will never go back. The clarity of explicitly declared interfaces and the freedom from header hell fundamentally changes how you think about organizing C++ code. Start a new project with modules if you don’t believe me. Try them. That is the largest barrier right now - downstream use. They are not supported because they are not used and they are not used because they are not well supported. But once you use them you will start to eagerly await every new compiler release in hopes of them receiving the attention they deserve.
- tsimionescu 1y ago
  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.
  - cyberax 1y ago
    Or a more relevant example: export templates.
  - deleted 1y ago
    [deleted]
- Kelteseth 1y ago
  Not sure why you are getting downvoted, but this alone would make me switch (Still waiting for Qt moc support): > No more weird forward declarations We c++ devs just have collectively accepted that this hack is still totally ok in the year 2025, just to improve build times.
deleted 1y ago
[deleted]
TylerGlaiel 1y ago
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
- reactordev 1y ago
  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.
  - feelamee 1y ago
    if no one wants to fix this 20yo codebase, why is there someone who wants to push it to the new C++ standard?
    - reactordev 1y ago
      You have it backwards. Everyone wants a new standard but no one wants to fix the code to make it work with a new way. They would rather introduce a whole new thing. We want new stuff, but in order to do that we must break old stuff. Like breaking old habits, except this one will never die.
      - bluGill 1y ago
        we spent a billion dollars to rewrite our code breaking everything. 15 years latter and we have a better product than the old stuff- but 15 years ago was pre c++11, and rust didn't exist. i cannot honestly ask for another billion dollars to repeat that again and we are stuck. We must keep the old code running and if your new thing isn't compatible with whatever we did back then you are off the table. c++26 still builds and runs that c++98 and so we can use it. Rust is nice but it can't interoperate as well in many ways and so it gets little use. you can call that bad desingn - I might even agree - but we are stuck.
wseqyrku 1y ago
had me at What to do with C++
monkeyelite 1y ago
I absolutely love having headers in C and stronger notions of compilation units. But in C++ you tend to want to push everything into headers to take advantage of generics. This is another problem where a separate code generation step would have been superior to language generics
sour-taste 1y ago
My belief is that modules were designed for big tech companies that do massive builds parallelized across thousands of machines. Such an environment makes the complexity bearable and you get massive speedups from cached build artifacts. I think smaller companies and hobbyists kinda got screwed.
- Kelteseth 1y ago
  Where does this belief come from? For that you can already use Mozillas sccache.
pizlonator 1y ago
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 with any other tech
- nitwit005 1y ago
  The Linux kernel is tens of millions of lines, so I'm rather doubtful at the existence of this OS over a billion lines.
  - uncircle 1y ago
    > 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.
  - pizlonator 1y ago
    That's just the kernel. An OS is more than the kernel
- aw1621107 1y ago
  > The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. I didn't think modules and separate compilation units are (completely) mutually exclusive? It's not like modules force you to use a single compilation unit for all your code; it just changes where the compilation unit boundaries/dependencies are (though to be fair I'm not entirely certain how much heavy lifting that "just" is doing) > Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that with any other tech It's not immediately obvious to me why this must be the case. That's the fundamental limitation of modules systems that supposedly prevents this scaling?
  - TuxSH 1y ago
nitwit005 1y ago
While I can see compiler authors not wanting to have to turn the compiler into a build system, I'd really appreciate if they did do that. Having to create makefiles or other build artifacts is such a waste of energy for most applications.
- bluGill 1y ago
  Build systems are far more complex than anyone thinks. If your build system doesn't cover all the weird things we do it is not usable at all.
  - flohofwoe 1y ago
    But oth, nothing is better at dealing with edge cases and weird things than writing your build scripts in an actual programming language. All that an integrated C++ build system would do is add a new std::build API, and for the compiler to discover a build.cpp file, compile and run that to perform the build. All the interesting "build system stuff" stuff would be implemented as regular stdlib code. See Zig for a working example of that idea (which also turned out to be a viable cmake replacement for C and C++ projects) It could even be reduced to compiler vendors agreeing on a convention to compile and run a build.cpp file. Everything else could live in 3rd party code shipped with a project.
    - bluGill 1y ago
      Real build systems need to deal with any language. Cargo is a negative on large projects because it has opinions that make things easy for small rust only projects and falls flat on complex projects- good build systems need to bea real programming language. The more declaritive the better - this is different from the project that often should be a different style
      - flohofwoe 1y ago
        As long as the build system can run external programs, you're really not limited to a single language (or even compiling source code). In the end build systems are just fancy task runners, no matter if they are integrated with a language toolchain or separate products.
kookamamie 1y ago
Fully agreed. The modules are an afterthought, and inevitably lead to a mess where we have both modules and includes all over the place.
Igwe_404 1y ago
I need more background and foundational insights for C++ control flow syntax for a pythonista who knows c like: I++ do {} while switch () case.
casualrandomcom 1y ago
"You might want to grab a cup of $beverage before continuing, this is going to take a while." Instead, I launched a compilation.
domenicd 1y ago
The standardization process here feels similar to what happened with JavaScript modules. Introduced in ES2015, but the language standard only had syntax and some invariants. It had no notion of how to load modules, or how they might be delivered, or how a program that had a module at its root might be started. But there was a similar urgency, of "we must have this in ES2015". I made it one of my first projects after joining the Chrome team to fix that gap, which we documented at [1]. (This reminds me of the article's "The only real way to get those done is to have a product owner...".) You could even stretch the analogy to talk about how standard JS modules compete against the hacked-together solutions of AMD or CommonJS modules, similar to C++ modules competing against precompiled headers. That said, the C++ modules problem seems worse than the JavaScript one. The technical design seems harder; JS's host/language separation seems cleaner than C++'s spec/compiler split. Perhaps most importantly, organizationally there was a clear place (the WHATWG) where all the browsers were willing to get together to work on a standard for JS module loading. Whereas it doesn't seem like there's as much of a framework for collaboration between C++ compiler writers. [1]: https://blog.whatwg.org/js-modules https://blog.whatwg.org/js-modules
WhereIsTheTruth 1y ago
They had an opportunity to finally get rid of requiring forward declaration, but they failed.. C++ has no future
whatsakandr 1y ago
He makes such a good point. This is such a tragedy. Import std would of been an amazing thing that would of led some much less pain, but the committee got greedy.
jmull 1y ago
> the "header inclusion" way is an O(N²) algorithm Maybe I don't know what they mean by this, but the header inclusion way is O(N*M), is it not? Where N is the number of source files and M is the average number of dependencies each has (as expressed as #includes). If M is approaching N -- meaning everything depends on everything -- you probably have bigger problems than compile times. That's also setting aside precompiled headers. Those wouldn't be N^2 either, even when the precompiled header needs to be precompiled.
achatham 1y ago
At Waymo we use c++ modules via clang and got the demanded 5x speedup. As the article mentions, you need a close relationship between the compiler and build system, which Google already has. The google build tooling team got modules to mostly work but only turned them on in limited situations. But we but the bullet and turned them on everywhere, which has sped up compilation of individual files by more than 5x (I forget the exact number). The remaining problem is that sometimes we get weird compilation errors and have to disable modules for that compilation unit. It's always around templates, and Eigen has been gnarly to get working.
vrighter 1y ago
what to do with them: try them, figure out that they're not supported by pretty much anything and thit when they do, they suck. Then move on with your life.

226 points by ingve 1y ago

holowoodman 1y ago

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

boppo1 1y ago
Sarcasm?
- grg0 1y ago
  These comments only reflect the person's narrow view of the "world", along with a generous dosage of pride to state things about which one does not know. If every OS and driver and much of the backbone of society is "legacy maintenance stuff", then the statement is certainly correct.
bukotron 1y ago
Rust does not solve any problem existing in expecienced C++ developer career. You dont write modern C++ code in such a way memory leak or dangling pointer is possible at all) This is exactly WHY we dont see a rush movement of C++ developers to Rust throwing away everything for Rust. Rust is trying to solve problems that already not exist 99.9999% of time in modern C++ code style and standards. Also, some day C++ compilers or tooling will get its own Borrow Checker to completely forget about Rust - this will be done just for fun just to stop arguing with rust-fans :)
- Philpax 1y ago
  Thinking that experience with C++'s many flaws will save you from running into them is delusional - just look at the number of CVEs in projects maintained by world-class C++ programmers. No amount of fallible human vigilance will stop you from forgetting the existence of a C++ quirk in the code you're rushing out before heading out for the night. Human oversight does not scale.
  - InCom-0 1y ago
    This is true ... except that Rust doesn't actually do any better in that regard. Rust solves 1 category of problems in a way that is not without its costs and other consequences. That is it. There are projects where this is very important, there are other projects where its virtually useless and the consequences just get in the way. It is not magic. It doesn't make anything actually 'safe'.
    - feelamee 1y ago
      sure, but don't forget that rust gives us also a nice tooling, functional syntax sugar like pattern matching, enums, monads; and other more or less useful things like explicit lifetimes
      - InCom-0 1y ago
        Of course. This is kind of to be expected as it has the benefit of hindsight of 25+ years. It is infinitely easier to design better things with all the accumulated experience and know-how of what works and what doesn't under your belt. It would have been truly horrifying if that had not been the case. That being said, Rust is really about lifetimes. That's the big ticket selling point. My point above was that 1) it isn't a silver bullet and 2) it can be a real hindrance is many applications.
      - flohofwoe 1y ago
        Tbh, only a mother can love Rust's syntax. It has even more "punctuation" than C++.
      - sobakistodor 1y ago
        [dead]
    - dlahoda 1y ago
      what is this 1 category?
  - flohofwoe 1y ago
    When looking at the number of CVEs you'll also have to take the amount of code written in that language into account, a language which has no users also has no CVEs ;) I bet there's easily tens of thousands of times more C++ code than Rust code out there.
- okanat 1y ago
  This is a very bad take. Rust does solve very real problems in C family languages. The number of people I met in Rust conferences that rewriting at least parts of rather big C++ codebases weren't small either. However, there is still big amount of code that is purely C++. Many of the older code bases still use C++03-style code too. Or they were written in the OOP design pattern golden era that requires huge reactors to adapt functional / modern code. Anything with Qt will not benefit from smart pointers. Even with Qt 6. Rust cannot solve these problems since the challenges are not purely technical but social too.
  - r_lee 1y ago
    I would say though that Rust has already had a profound social effect which has probably enabled those rewrites etc. It wasn't too long ago that it was brushed aside as noise yet now its gaining real momentum
c0balt 1y ago
I'm pretty sure a lot of fields would disagree with you. Last I checked game programming, OS development, embedded development and more were deeply invested in either C or more often C++, especially when RT tasks were involved or vendor-provided compilers are required. Rust just doesn't have close to the same type of adoption/support yet, especially when considering various embedded platforms.
- holowoodman 1y ago
  There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
  - jonathrg 1y ago
    C++ is widely used in embedded. Most compilers support it. Usually you turn some things off (e.g. -fno-rtti, -fno-exceptions) and try to stick to some sane subset of the ++.
    - com2kid 1y ago
      C++ in embedded is basically C with classes. It is a nice simple language and often doesn't even include templates (or if it does they are very simple data structures that are not even heap allocated). C++ as C with classes is a pretty good language!
      - deleted 1y ago
        [deleted]
  - grg0 1y ago
    Game engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.
okanat 1y ago
Newer stuff yes and it is great. However from basic rendering to browsers and the most complex applications (CAD, office software, finance, complex solvers like airline planning) are still in C++. Nobody will accept rewriting 35+ years of history. C++ code bases are really a lot longer-lived than any other software builds upon them. Hence we cannot drop it. Starting with C++17, I think committee has been doing the language a disservice and piled even more and more unintended complexity by rushing "improvements" like modules. I don't write C++ anymore due to my team switching to Rust and C only (for really old stuff and ABI). I am really scared of having to return though. Not because I am spoiled by Rust (I am though), but because catching up with all the silly things they added on top and how they interact with earlier stuff like iterators. C++ is a perfect language for unnecessary pitfalls. Newer standards just exploded this complexity.
- jonathrg 1y ago
  I understand and empathize with your fear. C++23 added a type with 22 constructors (http://en.cppreference.com/w/cpp/utility/expected/expected.html http://en.cppreference.com/w/cpp/utility/expected/expected.h...), that ought to be enough to strike fear into anyone.
  - okanat 1y ago
    It already has a defect report too: https://cplusplus.github.io/LWG/issue3886 https://cplusplus.github.io/LWG/issue3886 .
  - samiv 1y ago
    Don't worry, C++25 will deprecate half of them and C++27 will remove them while adding 20 new ones just to be deprecated in C++30.
    - okanat 1y ago
      C++ standard and deprecation is a contradiction. They almost never deprecate things. Things always go more complex.
whatevaa 1y ago
Borrow checker is actually not very good solution for some domains. I remember reading that it would not be good for writing javascript VM like v8. Something about managing memory which lifetime actually depends on others, not rust code.
fooker 1y ago
C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.
- Philpax 1y ago
  A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add, but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant` is, as far as I know, still limited, even in newer C++ code, because the ergonomics just aren't there.
  - fooker 1y ago
    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.
    - ghosty141 1y ago
      > 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 optional and expected are ergonomic nightmares since there is no "try!" macro like rust has. In general it lacks the infrastructure that is needed to make these types nice to use. It also clashes with other concepts like RAII where you kinda have to use exceptions when it comes to ctors that may fail.
diath 1y ago
There are a number of areas in programming where I'd always choose C++ over Rust - gameplay programming, retained-mode GUI programming and interpreted programming languages to name a few have very complex circular memory models that are somewhat solvable with weak_ptrs or refs stored in member variables passed through constructors but would be absolutely obnoxious to deal with and get right with the borrow checker.
- ozars 1y ago
  Rust has Arc and Weak that can be used for solving it in a similar way C++ does. The primary difference is forcing usage of Mutex to avoid a large class of data race issues IMHO, and that's what makes it harder to get right. Async in Rust is also more mature than C++ coroutines. So there's also that. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=02e9565e45119d0bdb9859544ad0d58c https://play.rust-lang.org/?version=nightly&mode=debug&editi...
  - MindSpunk 1y ago
    Arc/Weak can only get you so far. The problem I have with Rust in the mentioned domains (gameplay programming, retained GUI, interpreters) is what makes it so good, sharing xor mutability. If you're writing lots of multi-threaded code it's fantastic. If your problem domain is like the ones mentioned it hurts you. These are all highly non-parallel problems. They don't gain much from being parallel, and because Rust imposes 'restrict' semantics on even single threaded code you end up making it much harder to write code in these domains. This has been my experience with Rust. Shared mutability is safe on a single thread without 'restrict' on all your pointers, and Rust has limited options to opt into shared mutability (with lots of ergonomic caveats). Don't get me wrong though, I still think Rust is a great tool. It just has tradeoffs.
    - zozbot234 1y ago
      > Rust has limited options to opt into shared mutability The idiomatic Rust equivalent of a C non-restrict pointer is arguably &Cell<T>. The biggest problem with it is library code that takes &mut T when the likes of &Cell<T> might suffice (because potential aliasing does not affect the semantics of what that Rust code is doing), but this is an acknowledged problem and the Rust project will take pull req's that fix it where it occurs.
InCom-0 1y ago
Have a look at any serious job postings. C++ jobs outnumber Rust jobs somewhere around 50:1. Internet hype meets actual industry reality :-).
- tandr 1y ago
  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++?
  - lyu07282 1y ago
    I couldn't even tell if you are joking. Rust is weird, its like a programming language people developed a parasocial relationship with. If a Twitch streamer was a programming language it would be Rust. Perhaps its just people being immature I don't know.
    - feelamee 1y ago
      > I couldn't even tell if you are joking I'm thinking the same about your comment :D
      - lyu07282 1y ago
        It's a programming language with a fandom, isn't that odd? ^^
    - tandr 1y ago
      I was, but I guess adding /s at the end in these cases is a requirement nowadays...
  - Dylan16807 1y ago
    That's not devil's advocate, that's just being silly.
  - SkiFire13 1y ago
    Even if the basic idea might make sense there's no way the number if anywhere close to 1/50. Even 1/2 sounds unrealistic.
spacechild1 1y ago
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?
flohofwoe 1y ago
Rust isn't exactly famous for its fast build times. It's probably the only language that actually builds slower than C++, which is an impressive achievement on its own ;) And give Rust one or two more decades and it will be the same messy kitchen sink language as C++. If anything, Rust is speedrunning C++ history (with the notable exception of fixing static memory safety of course).

WalterBright 1y ago

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 compilation much faster, it was too sensitive to breakage. This experience was rolled into the design of D modules, which work like a champ. They were everything I wanted modules to be. In particular, The semantic meaning of the module is completely independent of wherever it is imported from. Anyhow, C++ is welcome to adopt the D design of modules. C++ would get modules that have 25 years of use, and are very satisfying. Yes, I do understand that the C preprocessor macros are a problem. My recommendation is, find language solutions to replace the preprocessor. C++ is most of the way there, just finish the job and relegate the preprocessor to the dustbin.

fooker 1y ago
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.
- WalterBright 1y ago
  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.
  - fooker 1y ago
    Neat, closed namespaces sound great! C++ has adapted the ‘using’ keyword now to seem fairly similar to alias, but can’t completely subsume macros unfortunately.
    - 1y ago

nurettin 1y ago

If you avoid circular refs and forward declarations by writing hierarchical code, you won't really need modules. In my current project I'm 20+ headers in and still haven't had a circular ref. Just refactor all the commonly used code, decouple with callbacks and you have yourself a nice clean header only library that you can amalgamate and/or precompile.

RossBencina 1y ago
> If you avoid circular refs See the book "Large Scale C++ Software Design" by John Lakos for more detail in this direction.

modeless 1y ago

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 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: https://github.com/pizlonator/fil-c https://github.com/pizlonator/fil-c

dgan 1y ago
what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests
- modeless 1y ago
  The catch is performance. It's not 200x slower though! 2x-4x is the actual range you can expect. There are many applications where that could be an acceptable tradeoff for achieving absolute memory safety of unmodified C/C++ code. But also consider that it's one guy's side project! If it was standardized and widely adopted I'm certain the performance penalty could be reduced with more effort on the implementation. And I'm also sure that for new C/C++ code that's aware of the performance characteristics of Fil-C that we could come up with ways to mitigate performance issues.
  - munificent 1y ago
    I mean, if I could accept a 2x-4x performance hit, then I wouldn't be using C++ in the first place. At that point, there are any of a number of other languages that are miles more pleasant to program in.
    - modeless 1y ago

forrestthewoods 1y ago

> modules should be killed and taken out of the standard. Yes. The C++ standard is an abomination that is both over-specified and wildly under-specified. Modules are simply never going to work en masse. It is a failed idea.

jeffbee 1y ago

Obligatory: https://arewemodulesyet.org/tools/ https://arewemodulesyet.org/tools/ Not great!

psyclobe 1y ago

Modules are unusable in real projects with real dependencies. Until that changes there’s no chance I’ll look at them.

feelamee 1y ago
how are modules related to dependencies in general? You can use your modules at the same time using dependencies via includes. And this works well.
- psyclobe 1y ago
  Can't include _any_ header downstream if you import std, it is also unknown how you're gonna export and share modules across dependencies you have no indention of 'porting' to modules...
  - feelamee 1y ago
    why everyone is fixated around `import std`?? Its only one library. If you can't use `import std` this is not mean that you can't use modules... > it is also unknown how you're gonna export and share modules across dependencies you have no indention of 'porting' to modules... as a first step you can introduce modules only in private interfaces of your lib. This is also absolutely valid usage.. There is no solution to invent modules in such way that everyone just switch compiler flag and have fun. If you expect this, so...

emtel 1y ago

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.

WalterBright 1y ago
D modules are very fast. Many of our customers rely on D being way faster than C++ to compile.
- feelamee 1y ago
  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.
  - WalterBright 1y ago
    Knowing D will make you a better programmer in other languages. For example, D pushes you to write better encapsulated modules, which is a transferable skill.
  - dzdt 1y ago
    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.
    - tialaramex 1y ago
      > Most languages that have made it big have been the primary language for a platform that made it big, I think you're going to want to define "made it big" and then make yourself some lists as this to me sounds like it doesn't have much explanatory power.

StephenHerlihyy 1y ago

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. Modules probably need a revision, and yes, adoption has been slow, but once you start using modules you will never go back. The clarity of explicitly declared interfaces and the freedom from header hell fundamentally changes how you think about organizing C++ code. Start a new project with modules if you don’t believe me. Try them. That is the largest barrier right now - downstream use. They are not supported because they are not used and they are not used because they are not well supported. But once you use them you will start to eagerly await every new compiler release in hopes of them receiving the attention they deserve.

tsimionescu 1y ago
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.
- cyberax 1y ago
  Or a more relevant example: export templates.
- deleted 1y ago
  [deleted]
Kelteseth 1y ago
Not sure why you are getting downvoted, but this alone would make me switch (Still waiting for Qt moc support): > No more weird forward declarations We c++ devs just have collectively accepted that this hack is still totally ok in the year 2025, just to improve build times.

deleted 1y ago

[deleted]

TylerGlaiel 1y ago

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

reactordev 1y ago
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.
- feelamee 1y ago
  if no one wants to fix this 20yo codebase, why is there someone who wants to push it to the new C++ standard?
  - reactordev 1y ago
    You have it backwards. Everyone wants a new standard but no one wants to fix the code to make it work with a new way. They would rather introduce a whole new thing. We want new stuff, but in order to do that we must break old stuff. Like breaking old habits, except this one will never die.
    - bluGill 1y ago
      we spent a billion dollars to rewrite our code breaking everything. 15 years latter and we have a better product than the old stuff- but 15 years ago was pre c++11, and rust didn't exist. i cannot honestly ask for another billion dollars to repeat that again and we are stuck. We must keep the old code running and if your new thing isn't compatible with whatever we did back then you are off the table. c++26 still builds and runs that c++98 and so we can use it. Rust is nice but it can't interoperate as well in many ways and so it gets little use. you can call that bad desingn - I might even agree - but we are stuck.

wseqyrku 1y ago

had me at What to do with C++

monkeyelite 1y ago

I absolutely love having headers in C and stronger notions of compilation units. But in C++ you tend to want to push everything into headers to take advantage of generics. This is another problem where a separate code generation step would have been superior to language generics

sour-taste 1y ago

My belief is that modules were designed for big tech companies that do massive builds parallelized across thousands of machines. Such an environment makes the complexity bearable and you get massive speedups from cached build artifacts. I think smaller companies and hobbyists kinda got screwed.

Kelteseth 1y ago
Where does this belief come from? For that you can already use Mozillas sccache.

pizlonator 1y ago

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 with any other tech

nitwit005 1y ago
The Linux kernel is tens of millions of lines, so I'm rather doubtful at the existence of this OS over a billion lines.
- uncircle 1y ago
  > 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.
- pizlonator 1y ago
  That's just the kernel. An OS is more than the kernel
aw1621107 1y ago
> The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. I didn't think modules and separate compilation units are (completely) mutually exclusive? It's not like modules force you to use a single compilation unit for all your code; it just changes where the compilation unit boundaries/dependencies are (though to be fair I'm not entirely certain how much heavy lifting that "just" is doing) > Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that with any other tech It's not immediately obvious to me why this must be the case. That's the fundamental limitation of modules systems that supposedly prevents this scaling?
- TuxSH 1y ago

nitwit005 1y ago

While I can see compiler authors not wanting to have to turn the compiler into a build system, I'd really appreciate if they did do that. Having to create makefiles or other build artifacts is such a waste of energy for most applications.

bluGill 1y ago
Build systems are far more complex than anyone thinks. If your build system doesn't cover all the weird things we do it is not usable at all.
- flohofwoe 1y ago
  But oth, nothing is better at dealing with edge cases and weird things than writing your build scripts in an actual programming language. All that an integrated C++ build system would do is add a new std::build API, and for the compiler to discover a build.cpp file, compile and run that to perform the build. All the interesting "build system stuff" stuff would be implemented as regular stdlib code. See Zig for a working example of that idea (which also turned out to be a viable cmake replacement for C and C++ projects) It could even be reduced to compiler vendors agreeing on a convention to compile and run a build.cpp file. Everything else could live in 3rd party code shipped with a project.
  - bluGill 1y ago
    Real build systems need to deal with any language. Cargo is a negative on large projects because it has opinions that make things easy for small rust only projects and falls flat on complex projects- good build systems need to bea real programming language. The more declaritive the better - this is different from the project that often should be a different style
    - flohofwoe 1y ago
      As long as the build system can run external programs, you're really not limited to a single language (or even compiling source code). In the end build systems are just fancy task runners, no matter if they are integrated with a language toolchain or separate products.

kookamamie 1y ago

Fully agreed. The modules are an afterthought, and inevitably lead to a mess where we have both modules and includes all over the place.

Igwe_404 1y ago

I need more background and foundational insights for C++ control flow syntax for a pythonista who knows c like: I++ do {} while switch () case.

casualrandomcom 1y ago

"You might want to grab a cup of $beverage before continuing, this is going to take a while." Instead, I launched a compilation.

domenicd 1y ago

The standardization process here feels similar to what happened with JavaScript modules. Introduced in ES2015, but the language standard only had syntax and some invariants. It had no notion of how to load modules, or how they might be delivered, or how a program that had a module at its root might be started. But there was a similar urgency, of "we must have this in ES2015". I made it one of my first projects after joining the Chrome team to fix that gap, which we documented at [1]. (This reminds me of the article's "The only real way to get those done is to have a product owner...".) You could even stretch the analogy to talk about how standard JS modules compete against the hacked-together solutions of AMD or CommonJS modules, similar to C++ modules competing against precompiled headers. That said, the C++ modules problem seems worse than the JavaScript one. The technical design seems harder; JS's host/language separation seems cleaner than C++'s spec/compiler split. Perhaps most importantly, organizationally there was a clear place (the WHATWG) where all the browsers were willing to get together to work on a standard for JS module loading. Whereas it doesn't seem like there's as much of a framework for collaboration between C++ compiler writers. [1]: https://blog.whatwg.org/js-modules https://blog.whatwg.org/js-modules

WhereIsTheTruth 1y ago

They had an opportunity to finally get rid of requiring forward declaration, but they failed.. C++ has no future

whatsakandr 1y ago

He makes such a good point. This is such a tragedy. Import std would of been an amazing thing that would of led some much less pain, but the committee got greedy.

jmull 1y ago

> the "header inclusion" way is an O(N²) algorithm Maybe I don't know what they mean by this, but the header inclusion way is O(N*M), is it not? Where N is the number of source files and M is the average number of dependencies each has (as expressed as #includes). If M is approaching N -- meaning everything depends on everything -- you probably have bigger problems than compile times. That's also setting aside precompiled headers. Those wouldn't be N^2 either, even when the precompiled header needs to be precompiled.

achatham 1y ago

At Waymo we use c++ modules via clang and got the demanded 5x speedup. As the article mentions, you need a close relationship between the compiler and build system, which Google already has. The google build tooling team got modules to mostly work but only turned them on in limited situations. But we but the bullet and turned them on everywhere, which has sped up compilation of individual files by more than 5x (I forget the exact number). The remaining problem is that sometimes we get weird compilation errors and have to disable modules for that compilation unit. It's always around templates, and Eigen has been gnarly to get working.

vrighter 1y ago

what to do with them: try them, figure out that they're not supported by pretty much anything and thit when they do, they suck. Then move on with your life.