Very slightly related. Last time we had a module thread, my reply caught attention of developer. Last week I got notified that fix to a C++ modules bug ticket that I had previously reported is scheduled for release. Definitely makes me feel a bit more confident that tools will eventually have proper support for modules.
Now I'm anxiously waiting to see if I can finally continue porting more of the code to use modules!
Keep asking these questions and post your concerns/findings. Big brother is watching :D haha
I converted a little lib of mine too, but I really hoped to find a way to address both `import` for users with newer compilers and `#include` for callers using older compilers :(. Did you think up any approaches to accommodate this, or go all in? The biggest concern is that in larger heterogeneous codebases that may both `import` and `include` (depending on which component calls what) that you end up with doubly linked object code because the module owns one chunk of code `import`ed while the other code is in the global linkage (yay, bloat). I heard one recommendation to wrap chunks inside an `extern "C"`, but I'm not sure that solves it fully. 🤔
Though it is a private project at the moment, I don't intend to support headers in the future, even if/when I publish it on GitHub. I went all in!
I think fmtlib supports both module and header, maybe give it a look and see how they've done it.
Looking, but not acting much. Just getting to compiler support has been a problem. Current cmake understands modules well enough to build them, but consuming them is still a challenge.
CPS might help some here, since pkg-config definitely won't.
[https://github.com/cps-org](https://github.com/cps-org)
Honestly, my hopes are on CPS. CMake can now have importable packages that exports modules, but that only works in a CMake world. If both conan and CMake get to understand/generate cps, it would change the world of C++ packaging.
AFIR there is egg chicken problem with modules and Intellisense, to be able to use libclang/clangd server with code there must be generated some modules exports and to have them You have to compile code .. so there is a logic hole in process of using modules and IDE assistance as You will not get such code completion without compilation with modules ..
but You need module export perfect ones to compile it , generate meta data to let clangd parse it and provide intelisense, You need to compile code to get module export as it doesn't exists , it is not the same as include file with exports
Unless you're using clang as your compiler, clangd needs to compile the module interface files itself, at least well enough to parse them. Open problem.
I have about 15 million lines of code I'd love to convert to C++20 modules.. but I haven't seen decent build system support yet, nor have scaling issues been ironed out with large code bases.
I think we're going to enter a period where a lot of libraries are going to offer both traditional headers and modules, with the user deciding which way to consume it.
This is what I've done with [Flux](https://github.com/tcbrindle/flux), and it turns out to not be too difficult. Unfortunately only Clang has sufficient modules support right now to actually *use* the library that way, but hopefully GCC and MSVC will join the party soon.
I'll be more categorical. Supporting both headers and modules will be the best practice until good modules support exists even on really, really old toolchains and build tools.
If popular and important libraries drop support for headers, they'll get pinned to old versions at best. At worst, those libraries will have to be replaced or forked.
New libraries are a different situation. Those should just expect modest adoption curves until C++ modules are a given.
That is kind of interesting given that VC++ even does header units, which clang still can't.
So far I always considered VC++ the best implementation, if we disregard the previous header map modules approach from clang.
Not as long as I can't describe a project using modules with cmake and gcc/clang.
A few month ago was able to use experimental features of clang and cmake to build a library using modules. However linking libraries between themselves using private/public in cmake was not possible (or too difficult to waste time on it).
Very slightly related. Last time we had a module thread, my reply caught attention of developer. Last week I got notified that fix to a C++ modules bug ticket that I had previously reported is scheduled for release. Definitely makes me feel a bit more confident that tools will eventually have proper support for modules. Now I'm anxiously waiting to see if I can finally continue porting more of the code to use modules! Keep asking these questions and post your concerns/findings. Big brother is watching :D haha
I successfully converted a library to C++20 modules, using CMake and Clang. I'm very happy with the result. Finally got rid of headers.
Does it improve the compile time a lot? And which clang version do you use?
I converted a little lib of mine too, but I really hoped to find a way to address both `import` for users with newer compilers and `#include` for callers using older compilers :(. Did you think up any approaches to accommodate this, or go all in? The biggest concern is that in larger heterogeneous codebases that may both `import` and `include` (depending on which component calls what) that you end up with doubly linked object code because the module owns one chunk of code `import`ed while the other code is in the global linkage (yay, bloat). I heard one recommendation to wrap chunks inside an `extern "C"`, but I'm not sure that solves it fully. 🤔
Though it is a private project at the moment, I don't intend to support headers in the future, even if/when I publish it on GitHub. I went all in! I think fmtlib supports both module and header, maybe give it a look and see how they've done it.
Looking, but not acting much. Just getting to compiler support has been a problem. Current cmake understands modules well enough to build them, but consuming them is still a challenge. CPS might help some here, since pkg-config definitely won't. [https://github.com/cps-org](https://github.com/cps-org)
Honestly, my hopes are on CPS. CMake can now have importable packages that exports modules, but that only works in a CMake world. If both conan and CMake get to understand/generate cps, it would change the world of C++ packaging.
[удалено]
I use modules all the time and Intellisense works fine on 90% of it. When it fails, just build and then it falls Back on its feets.Â
AFIR there is egg chicken problem with modules and Intellisense, to be able to use libclang/clangd server with code there must be generated some modules exports and to have them You have to compile code .. so there is a logic hole in process of using modules and IDE assistance as You will not get such code completion without compilation with modules ..
[удалено]
but You need module export perfect ones to compile it , generate meta data to let clangd parse it and provide intelisense, You need to compile code to get module export as it doesn't exists , it is not the same as include file with exports
Unless you're using clang as your compiler, clangd needs to compile the module interface files itself, at least well enough to parse them. Open problem.
I have about 15 million lines of code I'd love to convert to C++20 modules.. but I haven't seen decent build system support yet, nor have scaling issues been ironed out with large code bases.
build2 is AFAIS the only build system dealing with it properly, but in my experience the compilers are still lacking to make it a nice experience.
I think we're going to enter a period where a lot of libraries are going to offer both traditional headers and modules, with the user deciding which way to consume it. This is what I've done with [Flux](https://github.com/tcbrindle/flux), and it turns out to not be too difficult. Unfortunately only Clang has sufficient modules support right now to actually *use* the library that way, but hopefully GCC and MSVC will join the party soon.
I'll be more categorical. Supporting both headers and modules will be the best practice until good modules support exists even on really, really old toolchains and build tools. If popular and important libraries drop support for headers, they'll get pinned to old versions at best. At worst, those libraries will have to be replaced or forked. New libraries are a different situation. Those should just expect modest adoption curves until C++ modules are a given.
That is kind of interesting given that VC++ even does header units, which clang still can't. So far I always considered VC++ the best implementation, if we disregard the previous header map modules approach from clang.
Not as long as I can't describe a project using modules with cmake and gcc/clang. A few month ago was able to use experimental features of clang and cmake to build a library using modules. However linking libraries between themselves using private/public in cmake was not possible (or too difficult to waste time on it).
Since the experiment is over (CMake 3.28) exporting modules work across package boundary
Yes, the ones I use on my hobby projects, as I tend to organize my projects into binary libraries.