5 ms·

Modules are DOA and won’t happen even by C++32

pjmlp 2y ago
If portability isn't a concern, VC++ with MSBuild, or clang with CMake (without header units), are pretty much quite usable. However I do agree with the feeling for large scale adoption. The way modules and concepts went down, or the way GC API got added only to be removed, or ongoing contracts discussion, has pretty much settled my opinion that WG21 really needs to adopt the same approach as other programming language communities. Papers without working implementations for community feedback shouldn't be accepted at all.
- bluGill 2y ago
  That is generally the case. Modules had two different proposals with thair own implementation and they choose the one microsoft iplementet after debate which is why msvc had modules from the start.
  - pjmlp 2y ago
    The missing part of that story is that they ended up compromising on a third approach, without build tools support, with the hope everything would be quickly settled after shipping the standard. Apple and Google kept using clang header modules, switched focus to their C++ replacements, and clang transition to C++20 modules languished until a few heroes stepped in to do the work. Meanwhile GCC is still work in progress. And build tools are still a mess, even cmake doesn't have yet a story for header units. As for Microsoft, except for Office, there isn't a single Microsoft product, especially C++ SDKs, that make use of modules in any form. This is quite different from how other programming language ecosystems migrate features from preview into stable.
- chipdart 2y ago
  > However I do agree with the feeling for large scale adoption. I think that everyone has misguided and naive expectations on how such a radical change would roll out to production software. Changing dpendency management and updating build systems is a hard sell for professional projects delivering production software. It's the most radical change in how you're software is built with zero upside in terms of features. Best case scenario your software works as it always did. Worst case scenario you wasted tons of developement effort to retool and revamp your whole CICD pipeline just to break your project. Hard sell. I mean, why do people think so many projects are still stuck with C++11?
  - protomolecule 2y ago
    >zero upside Drastically reduced compilation time is a huge upside for modules.
    - chipdart 2y ago
      > Drastically reduced compilation time is a huge upside for modules. You can achieve those already with the adoption of basic architecture principles and the incorporation of tools like compiler caches such as ccache. Those who have an interest in those already do it. Modules are no silver bullet and change nothing.
      - protomolecule 2y ago
        Nope.
        chipdart 2y ago
        Following such an insightful response, I feel I should get back to my projects and ask them to build slower just to comply with your insight.
        protomolecule 2y ago
        People with bigger projects have to use something like this: https://userver.tech/d8/d4b/classutils_1_1FastPimpl.html https://userver.tech/d8/d4b/classutils_1_1FastPimpl.html

If portability isn't a concern, VC++ with MSBuild, or clang with CMake (without header units), are pretty much quite usable. However I do agree with the feeling for large scale adoption. The way modules and concepts went down, or the way GC API got added only to be removed, or ongoing contracts discussion, has pretty much settled my opinion that WG21 really needs to adopt the same approach as other programming language communities. Papers without working implementations for community feedback shouldn't be accepted at all.

bluGill 2y ago
That is generally the case. Modules had two different proposals with thair own implementation and they choose the one microsoft iplementet after debate which is why msvc had modules from the start.
- pjmlp 2y ago
  The missing part of that story is that they ended up compromising on a third approach, without build tools support, with the hope everything would be quickly settled after shipping the standard. Apple and Google kept using clang header modules, switched focus to their C++ replacements, and clang transition to C++20 modules languished until a few heroes stepped in to do the work. Meanwhile GCC is still work in progress. And build tools are still a mess, even cmake doesn't have yet a story for header units. As for Microsoft, except for Office, there isn't a single Microsoft product, especially C++ SDKs, that make use of modules in any form. This is quite different from how other programming language ecosystems migrate features from preview into stable.
chipdart 2y ago
> However I do agree with the feeling for large scale adoption. I think that everyone has misguided and naive expectations on how such a radical change would roll out to production software. Changing dpendency management and updating build systems is a hard sell for professional projects delivering production software. It's the most radical change in how you're software is built with zero upside in terms of features. Best case scenario your software works as it always did. Worst case scenario you wasted tons of developement effort to retool and revamp your whole CICD pipeline just to break your project. Hard sell. I mean, why do people think so many projects are still stuck with C++11?
- protomolecule 2y ago
  >zero upside Drastically reduced compilation time is a huge upside for modules.
  - chipdart 2y ago
    > Drastically reduced compilation time is a huge upside for modules. You can achieve those already with the adoption of basic architecture principles and the incorporation of tools like compiler caches such as ccache. Those who have an interest in those already do it. Modules are no silver bullet and change nothing.
    - protomolecule 2y ago
      Nope.
      - chipdart 2y ago
        Following such an insightful response, I feel I should get back to my projects and ask them to build slower just to comply with your insight.
        protomolecule 2y ago
        People with bigger projects have to use something like this: https://userver.tech/d8/d4b/classutils_1_1FastPimpl.html https://userver.tech/d8/d4b/classutils_1_1FastPimpl.html