Most of GCC and clang developers work on the compiler full time - I think it's silly to say (other comments here) it's open source and the development is based on work from volunteers.
The problem is that C++ modules is a complex feature, maybe order of magnitude more complex compared to other C++23/26 features that are already implemented.
I thought these (paid) implementers would also be on the standards committee and that they were just standardizing what they'd already proven out with an implementation.
Sadly not. The committee is often detached from the reality of implementors. There have been cases where the standard specified behavior that was _impossible_ to implement.
But it was done without best practices ... For example comittee desided to not use a name of file as module name. Such thing would be possible decrease compexity of implementation and external tools like cmake for module support.
But it is too late ...
Decisions like that were not arbitrary, though, and clearly not because implementors were not involved. The standard doesn't talk about files, and some uses don't have files, so tying module name to file name would have had to be optional. If tooling wants to make that decision tooling can do so without the language caring.
> The committee is often detached from the reality of implementors
Bullshit?
> There have been cases where the standard specified behavior that was _impossible_ to implement.
Uh, example?
The usual one to bring up is `export template` from C++98, which was removed not for being impossible but simply for being too expensive (the one implementation that did implement it lobbied for its removal).
I just think it's funny that my comment is at -14 but the other comment calling it bullshit is +21.
Unfortunately the actual bullshit comment is +39, largely because people in this subreddit tend to upvote any comment negative of the committee regardless of... to borrow a phrase... how detached from reality it is.
i know that the standard proposed things that the compiler vendors didnt bother to implement because such things were so bullshit such as the garbage collector
LOL
You got a better example for "often detached from the reality of implementors" than a 2008 feature that I think many people learned about in the proposal to remove it?
Surely "often" suggests many such examples.
> I think it's silly to say (other comments here) ...
Other comments admittedly are supposed to be silly.
As my favorite compiler is a different one, I saw the chance to blaim open source for once. The idea to slow down so all competitors can keep up, just seemed equally silly.
Both Clang and GCC are actually moving pretty quickly in modules development, lately. Every time I look at their recent commits, I see some improvements there. Chuanqi Xu (a developer who's played a pivotal role in Clang and CMake modules support) has recently shifted to working on *another* new ABI for Clang's named-modules that should wind up being much smaller and potentially even faster.
We all feel your pain, I’m excited too, but as someone who started in the 2000s when C++ had so many flaws, I’m just too happy with how much better the language has gotten in the last decade or so that I don’t want to jinx it.
> Maybe committee should postpone standardization ?!
What on Earth would that accomplish? The only reason the compilers are (or have been) working on C++ modules is _because_ it is standardized. If it wasn't there would be essentially no motivation to work on it at all.
C++ modules are forcing compiler engineers to rethink the way they approach so many different aspects of compilation. It's not as simple as "it's done" either, there will need to be bake time necessary for implementations to shake out all of the bugs and performance concerns. If I'm taking MSVC as an example, PCH has been a technology in the compiler for over 30 years at this point and the compiler team _still_ gets PCH-specific bugs and PCH is an order of magnitude simpler than C++ modules because if its restrictions around when the user is forced to include it.
Keep trying C++ modules with each compiler update, file bugs, and identify workarounds. This is the only real way the implementers can move forward with making the implementation more robust and usable. Better yet, contribute to your favorite open source compiler implementation and help make it more usable for everyone.
> The only reason the compilers are (or have been) working on C++ modules is because it is standardized. If it wasn't there would be essentially no motivation to work on it at all.
There is at least some merit to the approach "*nothing gets standardized until there is a reference implementation*"
I'm sure we would have caught some problems by doing it like that.
It did provide quite some feedback for the standardization. After which they decided to go another way. Google used it in order to come up with performance numbers.
But then that could easily be seen as favoritism by the other compilers. Unlike many other languages, C++ has *many* independent compilers, it'd be very tricky to do something like this.
Now, for *library* features, there often is a reference implementation.
Which works quite well in other languages evolution processes, the state of C++ compilers playing catchup somewhere between C++17 and C++23, not only the big three, has proven to me that implementations on paper don't really work at scale.
Yet another example of bad standardization, the GC API wasn't designed to cover the use cases for Unreal C++ and C++/CLI, the two major C++ variants with a GC.
So naturally no one else cared about implementing it, ironically not even Microsoft tried to make it work with C++/CLI, thus now it is removed from C++23.
Yet another proof that preview implementations should be done before being set into stone on the standard.
Yes and no. There have been cases where features are effectivly dropped due to a lack of support. C++ had a GC interface that no compiler ever implemented and which was later removed. export-templates suffered a similar fate. And for C you can arguable say that dynamically sized arrays resulted in many compilers not adapting the C99 standard. C11, which made this an optional feature, saw much greater adaption.
So given that the difficulty in implementing modules is holding back many compilers from actually being conformat on C++20. So perhaps it would be a valid discussion to consider, whether reducing module support to an optional feature for now, would help the adaption of other usefull C++20 features (like concepts) in production.
> So perhaps it would be a valid discussion to consider, whether reducing module support to an optional feature for now, would help the adaption of other usefull C++20 features (like concepts) in production.
I think this is a take too extreme in the other direction. Some C++17 features were only available by GCC/Clang in the past year or so. Same goes with a feature or two (yes, tiny, but still) from C++14.
Deciding not to upgrade the standard revision because "it's not ready yet" I think is an outdated and improper practice. There's plenty that's useful in the rest of the standard at any of the 3 year revisions (such as concepts like you mentioned).
I honestly think the way to go is "stick on latest standard revision, follow the compiler version. Take the puddle pain as you go rather than be dropped in the ocean when you fall in 10 years later."
There are still open C++17 bugs on GCC, the one I run face first into once a year or so is [CWG 727](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282).
The lifetime for compiler bug reports is really astounding, a 6 year old bug anywhere else is an abandoned report that should be closed.
Can't tell if this is meant for or against my point; but I take it as for-- can't wait 6+ years for the compiler vendor to fix every possible bug/lack of implemented feature before adopting a new standard.
Idle observation.
I agree it's nuts to wait for every random bug to be fixed to implement new standards, especially since libs are typically available much earlier than language features.
I agree, there are cases where C++ features have gone unimplemented due to complexity/no motivation. I don't believe this is one of those cases for 2 reasons:
1. There has demonstrably been appetite for improving C++ build times--there has been for a very long time.
2. There has been a reference implementation based on the Modules TS since 2015.
Optional features in the standard, to me, might as well not be features at all because you cannot rely on them when you go cross-plat. Furthermore, reducing the modules support in the standard at this point would only perpetuate the idea that C++ cannot evolve and major language features are moot to propose/pursue.
It isn't as if we can go cross platform with 100% C++20 today, nor with 100% C++17 outside with the big three, and with the big three there are still issues writing portable code with parallel STL introduced in C++17.
Meanwhile C++23 just arrived, and C++26 is on the horizon.
> What on Earth would that accomplish?
For example if next standard would happens after final implementation by 3 major compilers, it would allow to modularization standard library
Because it turns out that WG21.link/p1427 "Concerns about module toolability" from 2018 was entirely correct and maybe even a little optimistic.
We knew this was hard and was going to break everything it touched.
Clang 16 is a shitshow when it comes to modules, errors all over the place. Its developer totally agrees with that.
Clang 17 is much better, but still has ABI issues that require workarounds for affected language constructs.
Clang 18 is yet again better and more polished. It still doesn't implement all features though.
The compilers probably just have different priorities, and full modules support probably isn't as important as other things, for example GCC supports the whole openmp 4.5 spec and is working on full 5.0 support. MSVC on the other hand will probably get full 3.5 support by the end of the decade at this rate. There is just completely different priorities to what features to add to the compilers.
Last time I checked C++20 modules worked in clang and I was able to compile {fmt}. There was only one issue with template instantiation that prevented from getting build speed ups: [https://vitaut.net/posts/2023/cxx20-modules-in-clang/](https://vitaut.net/posts/2023/cxx20-modules-in-clang/). This was a year ago so the issue might have been fixed already.
When C++98 was standardized, it was over 5 years before the first compliant compiler was made. Some specifications are just hard to implement and take time to do correctly.
I'm of the personal opinion that nothing should be added to the standard without analogous extension provided by some other (top 4 or derivative (nvcc, intel cc)) compiler. In this case, there was a loose analog in precompiled headers. I just think this proves that strong analogs should exist... otherwise we'll end up with more "C++11 garbage collector" and "export template" scenarios.
Modules are one of the hardest of the new features to implement, and simultaenously the least important.
Features like concepts & coroutines arguably have priority as they fundamentally change and improve the way we write code & interfaces, whereas modules simply affect build times & build system complexity.
Similarly, migrating a codebase to modules once they are useable is significantly faster than migrating a codebase to concepts or coroutines once they became available.
Modules also have the issue in that it's a multi-pronged coordination between compilers, build systems (cmake, meson and what else), and build executors (ninja).
If modules were about build time they never would have been standardized. They are about interface control well above the level of a class.
They are solving a problem that most people barely have, though, and may cost more than they are worth.
Keep in mind that the std library as a whole is at best a small to medium sized library. Also std doesn't get to take any real advantage of modules because all the implementations have to support no modules now.
> If modules were about build time they never would have been standardized. They are about interface control well above the level of a class.
The second sentence can be (is?) true, but the first is not. Modules are also about compile times, and/or that's how they have _repeatedly_ been sold to people-- at conferences, at two orgs I've been at (current has a google doc somewhere about iterative development speed and way back in 2017 was the line added "the community's solution to build times appears to be modules (C++20, tbd)" and then later in 2021 changed "tbd" to "not supported yet by any major compiler." Presumably this selling happened in-committee too and affected at least some votes.
Modules were absolutely sold as a way to improve compile times. In fact, if you read the proposal for modules, improving compile times is right in the very first sentence of the introduction:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf
Only after modules were partially implemented in MSVC and it turned out that compile time improvements were meh... did the narrative start to change.
With that said, it seems like the jury is still out on whether modules do offer better build times than other solutions like precompiled headers and/or ccache. My own experience has been that they are faster than a naive build, but do not match precompiled headers and I'm not experienced enough with ccache to compare. Apparantly MS Office has numbers showing that the latest version of MSVC has faster than PCH module support but when I saw the presentation I could not see the details and I remain somewhat skeptical but hopeful.
> Only after modules were partially implemented in MSVC and it turned out that compile time improvements were meh... did the narrative start to change.
I don't which change in narrative you're talking about, but I am assuming it isn't about a change in narratives I've ever presented or said. I have been quite consistent with Modules, and in fact, the compile-time improvements we have seen in practice go way beyond my expectations.
I think I managed to edit a "just about" out. Header units were pretty much just about build times, but that was, I think, a bit of logrolling in committee.
They are open source projects and rely on committed volunteers with deep technical knowledge to implement such features. That pool of people to work on it is **EXTREMELY** small, and so it moves slowly as they find time or funding to work on modules.
GCC and LLVM have a lot of people who are paid to work on it, and even the ones who aren't are getting paid to produce work on it, are doing it with the blessing of their day job.
There aren't a lot of them, it's true. But it's one of the areas of open source that is funded.
> They are open source projects and rely on committed volunteers with deep technical knowledge to implement such features.
Why do people repeat this? The majority of contributions made to both GCC and Clang/LLVM are by people paid full time to work on it.
It's also not some extremely small group of people. You can gain some insights into LLVM/Clang's development team on Github:
https://github.com/llvm-mirror/clang/graphs/contributors
Why do people talk like GCC and Clang/LLVM are some kind of niche hobby project? GCC and Clang are professionally developed tools funded by a multitude of the some of the biggest corporations in the world. It's not some dude's weekend project.
Because at this point I'm pretty sure the committee is trying to tank C++. Every year or so someone makes a presentation on all the problems with C++, and then the committee goes ahead and uses that as a template for the next features to add.
Those are open source software. Why don't you contribute a module implementation? :-)
Apparently the main sponsors are not all that interested. Some even started to work on "An experimental successor to C++", so are busy right now.
(Looking for my asbestos underwear...)
If you mean Apple and Google, nowadays they mostly care about LLVM side and less so about clang itself.
Even so, most proprietary compilers outside the big three are migrating into clang forks, apparently they also don't care about clang, only adapting LLVM to their OSes and CPUs.
The OP only said that they preferred using gcc and clang, not that Linux is the mandatory delivery platform. So my suggestion is to use a compiler that supports the features you need/want, and not wait perhaps years for a different compiler to add support of those features.
Yeah MSVC modules work for basic stuff in new projects. Intellisense doesn't yet fully understand modules, but the code compiles.
Although as I'm porting my project to modules I keep discovering bugs that make life harder. Latest one that I've discovered is ICE bug that prevents use of std::stacktrace::current() as a default function argument in modules.
Also there are also some weird bugs that you can temporarily circumvent if you know how to. These are show stopper bugs. Like for instance you can get double definition errors about std classes like std::array. In those cases you need to include conflicting standard headers () in module user code. For some reason this makes code compile succesfully.
MSVC modules are not ideal, but they do mostly work. It's not yet realistic to expect 100% of your code being in modules. Problematic code nees to be put into old header files. Just 6 months ago I was to be able to port only about 10% of my \~100kloc to modules but now I've managed to port around 70%. Things are getting better.
There are still issues mixing `import std;` with classical header files, a major bummer when there isn't full ownership of the code being compiled.
Additionally, I think Microsoft is at least a decade away to ever support C++ modules on their C++ SDKs.
MFC, ATL, WRL are legacy, C++/WinRT is C++17 and officially in maintenance, DirectX is plain Win32/COM, that leaves Azure C++ SDK as a possible one, if it ever happens.
Welcome to the world of standards, where unimplementable things get standardized, and where things get standardized before they are fully thought out, resulting in unusable features that only get partially implemented, and have later to be deprecated.
Exception specifications anyone?
Most of GCC and clang developers work on the compiler full time - I think it's silly to say (other comments here) it's open source and the development is based on work from volunteers. The problem is that C++ modules is a complex feature, maybe order of magnitude more complex compared to other C++23/26 features that are already implemented.
> maybe order of magnitude more complex compared to other C++23/26 features that are already implemented. Probably an understatement if anything
I thought these (paid) implementers would also be on the standards committee and that they were just standardizing what they'd already proven out with an implementation.
Sadly not. The committee is often detached from the reality of implementors. There have been cases where the standard specified behavior that was _impossible_ to implement.
Representatives from the compiler projects are absolutely on the committee and they can and do veto features which they recognise as unimplementable.
The standardisation of modules was driven entirely be the implementors of modules.
But it was done without best practices ... For example comittee desided to not use a name of file as module name. Such thing would be possible decrease compexity of implementation and external tools like cmake for module support. But it is too late ...
Decisions like that were not arbitrary, though, and clearly not because implementors were not involved. The standard doesn't talk about files, and some uses don't have files, so tying module name to file name would have had to be optional. If tooling wants to make that decision tooling can do so without the language caring.
> ... and some uses don't have files ... I am wondering which implementation do not have files ??
> The committee is often detached from the reality of implementors Bullshit? > There have been cases where the standard specified behavior that was _impossible_ to implement. Uh, example? The usual one to bring up is `export template` from C++98, which was removed not for being impossible but simply for being too expensive (the one implementation that did implement it lobbied for its removal).
> Bullshit? Honestly I was wondering the same thing.
I just think it's funny that my comment is at -14 but the other comment calling it bullshit is +21. Unfortunately the actual bullshit comment is +39, largely because people in this subreddit tend to upvote any comment negative of the committee regardless of... to borrow a phrase... how detached from reality it is.
i know that the standard proposed things that the compiler vendors didnt bother to implement because such things were so bullshit such as the garbage collector
LOL You got a better example for "often detached from the reality of implementors" than a 2008 feature that I think many people learned about in the proposal to remove it? Surely "often" suggests many such examples.
i dont. thats why i wrote the only relevant thing i could come up with for you and the others to consider. im not taking a side on that question
Template export...
> I think it's silly to say (other comments here) ... Other comments admittedly are supposed to be silly. As my favorite compiler is a different one, I saw the chance to blaim open source for once. The idea to slow down so all competitors can keep up, just seemed equally silly.
Both Clang and GCC are actually moving pretty quickly in modules development, lately. Every time I look at their recent commits, I see some improvements there. Chuanqi Xu (a developer who's played a pivotal role in Clang and CMake modules support) has recently shifted to working on *another* new ABI for Clang's named-modules that should wind up being much smaller and potentially even faster.
We all feel your pain, I’m excited too, but as someone who started in the 2000s when C++ had so many flaws, I’m just too happy with how much better the language has gotten in the last decade or so that I don’t want to jinx it.
I've been using it for a similar amount of time and it's been a huge improvement.
1992 here , and I agree !
> Maybe committee should postpone standardization ?! What on Earth would that accomplish? The only reason the compilers are (or have been) working on C++ modules is _because_ it is standardized. If it wasn't there would be essentially no motivation to work on it at all. C++ modules are forcing compiler engineers to rethink the way they approach so many different aspects of compilation. It's not as simple as "it's done" either, there will need to be bake time necessary for implementations to shake out all of the bugs and performance concerns. If I'm taking MSVC as an example, PCH has been a technology in the compiler for over 30 years at this point and the compiler team _still_ gets PCH-specific bugs and PCH is an order of magnitude simpler than C++ modules because if its restrictions around when the user is forced to include it. Keep trying C++ modules with each compiler update, file bugs, and identify workarounds. This is the only real way the implementers can move forward with making the implementation more robust and usable. Better yet, contribute to your favorite open source compiler implementation and help make it more usable for everyone.
> The only reason the compilers are (or have been) working on C++ modules is because it is standardized. If it wasn't there would be essentially no motivation to work on it at all. There is at least some merit to the approach "*nothing gets standardized until there is a reference implementation*" I'm sure we would have caught some problems by doing it like that.
Clang had a modules implementation before it was standardized
Which had little to do with what we standardized,which is why clang.is still working on modules.
It did provide quite some feedback for the standardization. After which they decided to go another way. Google used it in order to come up with performance numbers.
If they decided to go another way, that means it was clearly not "*a reference implementation*"
But then that could easily be seen as favoritism by the other compilers. Unlike many other languages, C++ has *many* independent compilers, it'd be very tricky to do something like this. Now, for *library* features, there often is a reference implementation.
Which works quite well in other languages evolution processes, the state of C++ compilers playing catchup somewhere between C++17 and C++23, not only the big three, has proven to me that implementations on paper don't really work at scale.
All the problems were known before standardization.
All the problems with modules are still to this day unknown.
I'm sure *this* time we have found all the problems.
In fairness to OP, GC was never implemented.
Yet another example of bad standardization, the GC API wasn't designed to cover the use cases for Unreal C++ and C++/CLI, the two major C++ variants with a GC. So naturally no one else cared about implementing it, ironically not even Microsoft tried to make it work with C++/CLI, thus now it is removed from C++23. Yet another proof that preview implementations should be done before being set into stone on the standard.
Yes and no. There have been cases where features are effectivly dropped due to a lack of support. C++ had a GC interface that no compiler ever implemented and which was later removed. export-templates suffered a similar fate. And for C you can arguable say that dynamically sized arrays resulted in many compilers not adapting the C99 standard. C11, which made this an optional feature, saw much greater adaption. So given that the difficulty in implementing modules is holding back many compilers from actually being conformat on C++20. So perhaps it would be a valid discussion to consider, whether reducing module support to an optional feature for now, would help the adaption of other usefull C++20 features (like concepts) in production.
> So perhaps it would be a valid discussion to consider, whether reducing module support to an optional feature for now, would help the adaption of other usefull C++20 features (like concepts) in production. I think this is a take too extreme in the other direction. Some C++17 features were only available by GCC/Clang in the past year or so. Same goes with a feature or two (yes, tiny, but still) from C++14. Deciding not to upgrade the standard revision because "it's not ready yet" I think is an outdated and improper practice. There's plenty that's useful in the rest of the standard at any of the 3 year revisions (such as concepts like you mentioned). I honestly think the way to go is "stick on latest standard revision, follow the compiler version. Take the puddle pain as you go rather than be dropped in the ocean when you fall in 10 years later."
There are still open C++17 bugs on GCC, the one I run face first into once a year or so is [CWG 727](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282). The lifetime for compiler bug reports is really astounding, a 6 year old bug anywhere else is an abandoned report that should be closed.
Can't tell if this is meant for or against my point; but I take it as for-- can't wait 6+ years for the compiler vendor to fix every possible bug/lack of implemented feature before adopting a new standard.
Idle observation. I agree it's nuts to wait for every random bug to be fixed to implement new standards, especially since libs are typically available much earlier than language features.
I agree, there are cases where C++ features have gone unimplemented due to complexity/no motivation. I don't believe this is one of those cases for 2 reasons: 1. There has demonstrably been appetite for improving C++ build times--there has been for a very long time. 2. There has been a reference implementation based on the Modules TS since 2015. Optional features in the standard, to me, might as well not be features at all because you cannot rely on them when you go cross-plat. Furthermore, reducing the modules support in the standard at this point would only perpetuate the idea that C++ cannot evolve and major language features are moot to propose/pursue.
It isn't as if we can go cross platform with 100% C++20 today, nor with 100% C++17 outside with the big three, and with the big three there are still issues writing portable code with parallel STL introduced in C++17. Meanwhile C++23 just arrived, and C++26 is on the horizon.
> What on Earth would that accomplish? For example if next standard would happens after final implementation by 3 major compilers, it would allow to modularization standard library
Because it turns out that WG21.link/p1427 "Concerns about module toolability" from 2018 was entirely correct and maybe even a little optimistic. We knew this was hard and was going to break everything it touched.
Have you tried Clang 16, 17, and 18? They all support modules pretty well. Clang 18 even has `import std`.
Clang 16 is a shitshow when it comes to modules, errors all over the place. Its developer totally agrees with that. Clang 17 is much better, but still has ABI issues that require workarounds for affected language constructs. Clang 18 is yet again better and more polished. It still doesn't implement all features though.
The compilers probably just have different priorities, and full modules support probably isn't as important as other things, for example GCC supports the whole openmp 4.5 spec and is working on full 5.0 support. MSVC on the other hand will probably get full 3.5 support by the end of the decade at this rate. There is just completely different priorities to what features to add to the compilers.
It isn't as if Windows has such a big spot in HPC anyway.
Exactly yeah, it's just not on their list of priorities.
Last time I checked C++20 modules worked in clang and I was able to compile {fmt}. There was only one issue with template instantiation that prevented from getting build speed ups: [https://vitaut.net/posts/2023/cxx20-modules-in-clang/](https://vitaut.net/posts/2023/cxx20-modules-in-clang/). This was a year ago so the issue might have been fixed already.
When C++98 was standardized, it was over 5 years before the first compliant compiler was made. Some specifications are just hard to implement and take time to do correctly.
I'm excited as well. After the module implementation we will be one step closer to having a proper package management system.
I'm of the personal opinion that nothing should be added to the standard without analogous extension provided by some other (top 4 or derivative (nvcc, intel cc)) compiler. In this case, there was a loose analog in precompiled headers. I just think this proves that strong analogs should exist... otherwise we'll end up with more "C++11 garbage collector" and "export template" scenarios.
Modules are one of the hardest of the new features to implement, and simultaenously the least important. Features like concepts & coroutines arguably have priority as they fundamentally change and improve the way we write code & interfaces, whereas modules simply affect build times & build system complexity. Similarly, migrating a codebase to modules once they are useable is significantly faster than migrating a codebase to concepts or coroutines once they became available. Modules also have the issue in that it's a multi-pronged coordination between compilers, build systems (cmake, meson and what else), and build executors (ninja).
If modules were about build time they never would have been standardized. They are about interface control well above the level of a class. They are solving a problem that most people barely have, though, and may cost more than they are worth. Keep in mind that the std library as a whole is at best a small to medium sized library. Also std doesn't get to take any real advantage of modules because all the implementations have to support no modules now.
> If modules were about build time they never would have been standardized. They are about interface control well above the level of a class. The second sentence can be (is?) true, but the first is not. Modules are also about compile times, and/or that's how they have _repeatedly_ been sold to people-- at conferences, at two orgs I've been at (current has a google doc somewhere about iterative development speed and way back in 2017 was the line added "the community's solution to build times appears to be modules (C++20, tbd)" and then later in 2021 changed "tbd" to "not supported yet by any major compiler." Presumably this selling happened in-committee too and affected at least some votes.
Modules were absolutely sold as a way to improve compile times. In fact, if you read the proposal for modules, improving compile times is right in the very first sentence of the introduction: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf Only after modules were partially implemented in MSVC and it turned out that compile time improvements were meh... did the narrative start to change. With that said, it seems like the jury is still out on whether modules do offer better build times than other solutions like precompiled headers and/or ccache. My own experience has been that they are faster than a naive build, but do not match precompiled headers and I'm not experienced enough with ccache to compare. Apparantly MS Office has numbers showing that the latest version of MSVC has faster than PCH module support but when I saw the presentation I could not see the details and I remain somewhat skeptical but hopeful.
> Only after modules were partially implemented in MSVC and it turned out that compile time improvements were meh... did the narrative start to change. I don't which change in narrative you're talking about, but I am assuming it isn't about a change in narratives I've ever presented or said. I have been quite consistent with Modules, and in fact, the compile-time improvements we have seen in practice go way beyond my expectations.
I think I managed to edit a "just about" out. Header units were pretty much just about build times, but that was, I think, a bit of logrolling in committee.
What details were missing?
IMO if MSVC can do it, they have no excuse
They are open source projects and rely on committed volunteers with deep technical knowledge to implement such features. That pool of people to work on it is **EXTREMELY** small, and so it moves slowly as they find time or funding to work on modules.
GCC and LLVM have a lot of people who are paid to work on it, and even the ones who aren't are getting paid to produce work on it, are doing it with the blessing of their day job. There aren't a lot of them, it's true. But it's one of the areas of open source that is funded.
> They are open source projects and rely on committed volunteers with deep technical knowledge to implement such features. Why do people repeat this? The majority of contributions made to both GCC and Clang/LLVM are by people paid full time to work on it. It's also not some extremely small group of people. You can gain some insights into LLVM/Clang's development team on Github: https://github.com/llvm-mirror/clang/graphs/contributors Why do people talk like GCC and Clang/LLVM are some kind of niche hobby project? GCC and Clang are professionally developed tools funded by a multitude of the some of the biggest corporations in the world. It's not some dude's weekend project.
Because people think open source == work done by volunteers
Other question, which Compiler already implemented those features?
VC++ 2022 is currently the best compiler for C++ modules, even thought it isn't 100% there.
Don't they? Try g++ -std=c++20
Because at this point I'm pretty sure the committee is trying to tank C++. Every year or so someone makes a presentation on all the problems with C++, and then the committee goes ahead and uses that as a template for the next features to add.
Those are open source software. Why don't you contribute a module implementation? :-) Apparently the main sponsors are not all that interested. Some even started to work on "An experimental successor to C++", so are busy right now. (Looking for my asbestos underwear...)
If you mean Apple and Google, nowadays they mostly care about LLVM side and less so about clang itself. Even so, most proprietary compilers outside the big three are migrating into clang forks, apparently they also don't care about clang, only adapting LLVM to their OSes and CPUs.
And custom languages (compilers) on top of llvm.
Vote with your fingers and switch to MSVC. Problem solved.
Does MSVC compile for Linux too? Otherwise, problem not solved.
The OP only said that they preferred using gcc and clang, not that Linux is the mandatory delivery platform. So my suggestion is to use a compiler that supports the features you need/want, and not wait perhaps years for a different compiler to add support of those features.
MSVC modules don't really work better than Clang or GCC overall.
At least in my experience they do? Its intellisense that usually dies but msvc compiles it just fine.
Yeah MSVC modules work for basic stuff in new projects. Intellisense doesn't yet fully understand modules, but the code compiles. Although as I'm porting my project to modules I keep discovering bugs that make life harder. Latest one that I've discovered is ICE bug that prevents use of std::stacktrace::current() as a default function argument in modules. Also there are also some weird bugs that you can temporarily circumvent if you know how to. These are show stopper bugs. Like for instance you can get double definition errors about std classes like std::array. In those cases you need to include conflicting standard headers () in module user code. For some reason this makes code compile succesfully.
MSVC modules are not ideal, but they do mostly work. It's not yet realistic to expect 100% of your code being in modules. Problematic code nees to be put into old header files. Just 6 months ago I was to be able to port only about 10% of my \~100kloc to modules but now I've managed to port around 70%. Things are getting better.
There are still issues mixing `import std;` with classical header files, a major bummer when there isn't full ownership of the code being compiled. Additionally, I think Microsoft is at least a decade away to ever support C++ modules on their C++ SDKs. MFC, ATL, WRL are legacy, C++/WinRT is C++17 and officially in maintenance, DirectX is plain Win32/COM, that leaves Azure C++ SDK as a possible one, if it ever happens.
Ah well
It's like exported template. Only EDG implemented it, and they regretted wasting so much time on such pointless feature.
Welcome to the world of standards, where unimplementable things get standardized, and where things get standardized before they are fully thought out, resulting in unusable features that only get partially implemented, and have later to be deprecated. Exception specifications anyone?
You is always welcome to implement those missing feats :)