I've been working professionally with c++ since 2001, and I'm currently a team lead.<p>The compensation packages we are able to offer to new hires means we're generally hiring from the middle of the talent pool, not the upper tier.<p>The complexity of c++ has long since outpaced the pace of fluency of the hiring pool. In my experience, the average c++ professional (that applies for our open job ads) knows c++14, and might not balk at an occasional c++17 feature.<p>It doesn't matter if the compilers support modules or not, because in practice, I won't be able to use modules in the workplace for ages.<p>--<p>Standard disclaimer - I'm not able to predict the crush of changes coming as generative AI for software development proliferates.
I wrote my own build system to use C++20 modules before CMake even had support for them, and while I have probably had net benefit from using them, I can’t recommend them for anyone in their own projects at this point.<p>The feature has so many irregularities that could only come out of a standards process, there are too many compiler bugs (just try using header units), the different implementations are too fragmented (I’m only using clang, which makes this easier on me), and there is a lack of things like module maps that would dramatically improve usability.
I love this having just started reading through the C++ 20 stuff.<p>However, a key opportunity is missed in that neither the icon nor the site links in the footer linked to a short definition of the language before modules (the lack), the impact of modules on the design of the language at present (the real) and its place in the future of programming languages (the imaginary and the symbolic).
After writing build systems for a C/C++ operating system and years optimising builds for C/C++ operating systems the major disaster by far is the C preprocessor.<p>This is the source of all the evil. Even a hello world program involves reading through 100s of kilobytes, often megabytes, of headers that have to be parsed again and again for every source file but which can produce totally different outcomes in each case depending on compilers and the OS and the definitions on the commandline and whatever's defined in the source code itself and how the filesystem is laid out.<p>You can forget managing the dependencies on large projects this way - they are overwhelming. Every build system tends to be leaky and imperfect to not get drowned in dependencies and the fanciest systems all tend to have big holes here or there or they have to use huge "catchall" dependencies to try to be correct at the cost of efficiency.<p>I hoped modules would remove this problem but so far I'm not sure. I'd love to get the opinion of someone who has used them. My read-ups about it didn't seem that hopeful - I got the impression of them being a bit like pre-compiled headers.
I think calling GCC's support of modules "partial" is a tad generous. It's pretty easy to hit ICEs/segfaults when trying to use modules with GCC, which is a good reason why it's not worth it for libraries to support modules at all.
Standard library support is not there in any meaningful way across compilers, I fail to see why anyone would adopt modules at the present. MSVC is the furthest along in its support last I looked. Once compiler support is available, I would expect usage to increase fairly rapidly. As with many things C++, modules are a nice-to-have, adopting a successful strategy from other languages/ecosystems, and many will choose to never adopt them.
Estimated completion by 3892 is cute, but not surprising really given that only 1/4 compilers and 1/3 stdlibs support these completely. Presumably most projects aren't going to try to migrate until it's more generally available (I haven't looked at them in years, not sure if it's easy or possible to support it for one toolchain but not another).
Some notes:<p>This website scrapes vcpkg's registry[1], which contains many <i>C</i> libraries which are unlikely to ever receive C++20 module updates. Many are primarily <i>binary executable</i> packages, like lunarg-vulkantools. It is quite unfair to judge C++ module support by this. There are even bugs in the table: the issue tracking Vulkan-Hpp module links to <a href="https://github.com/KhronosGroup/Vulkan-Hpp/issues/121">https://github.com/KhronosGroup/Vulkan-Hpp/issues/121</a>, but it was actually implemented in <a href="https://github.com/KhronosGroup/Vulkan-Hpp/issues/1580">https://github.com/KhronosGroup/Vulkan-Hpp/issues/1580</a> (full disclosure: I implemented it).<p>Boost maintainers have picked up on this[2], which is big.<p>The big 3 compilers have had a myriad of bugs, ICEs, and redefinition errors, despite what is claimed on cppreference[3]. VS 2022 17.10 will only just fix some of these, and G++'s module support isn't even released yet. Clang 18 has seemingly full(er) support for C++20 modules, but clang<i>d</i> is broken, and it seems mixing standard library headers and `import std` might still break, as will header units (`import <header>`).<p>CMake released C++20 modules support with 3.28, and will release `import std` support with 3.30.<p>This is painful but IMO worth the paper cuts that the bleeding-edge adopters will experience in the next year or so as modules are implemented.<p>I fully believe that a good one-third to half of build time and power consumption in the past 40+ years of compiling C and C++ code (considerably more so in the case of template-heavy C++ header-only libraries and projects) has gone to parsing and re-parsing headers and the resultant output.<p>Headers are a distinctly 1970s approach to compartmentalisation. Other languages have sorted dependency and library/import resolution years ago; there's no reason the C and C++ world has to be stuck with essentially copy-pasting code over and over. The embarrassingly parallel building that results from headers is fake; it takes more time and more energy than strictly necessary.<p>[1]: <a href="https://vcpkg.link/browse/all" rel="nofollow">https://vcpkg.link/browse/all</a><p>[2]: <a href="https://anarthal.github.io/cppblog/modules" rel="nofollow">https://anarthal.github.io/cppblog/modules</a><p>[3]: <a href="https://en.cppreference.com/w/cpp/compiler_support/20" rel="nofollow">https://en.cppreference.com/w/cpp/compiler_support/20</a>
As of this writing the term "debug" has not appeared a single time in any part of these discussion. What's the vscode step through debugger experience for C++ modules?
Silly question: What's the difference between C++20 modules and <a href="https://conan.io" rel="nofollow">https://conan.io</a>? (Google was vague, and ChatGPT, you know, sometimes makes things up so I rather ask fellow humans...)<p>(edit: Conan seem to address C++20 modules, seems to seek compatibility, but as a non CPP developer, not sure I read it right <a href="https://blog.conan.io/2023/10/17/modules-the-packaging-story.html" rel="nofollow">https://blog.conan.io/2023/10/17/modules-the-packaging-story...</a>)
Is it just me or does it seem like modules are a good idea which is totally dead on arrival? It's been four years, and we've had a whole new edition of c++ standard in the meantime, and Clang and GCC still don't have full support for modules.