4 ms·

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

by duped 7mo ago

jjmarr 7mo ago
You're not supposed to distribute the precompiled module file. You are supposed to distribute the source code of the module. Header-only projects are the best to convert to modules because you can put the implementation of a module in a "private module fragment" in that same file and make it invisible to users. That prevents the compile-time bloat many header-only dependencies add. It also avoids distributing a `.cpp` file that has to be compiled and linked separately, which is why so many projects are header-only.
- duped 7mo ago
  What I mean is, I have yet to see projects in the wild _use modules at all_.
  - pjmlp 7mo ago
    Plenty of examples on Github, Microsoft has talks on how Office has migrated to modules, and the Vulkan updated tutorials from Khronos, have an optional learning path with modules.
FrostKiwi 7mo ago
It's the fault of built systems. CMake still doesn't support `import std` officially and undocumented things are done in the ecosystem [1] But once it works and you setup the new stuff, having started a new CPP26 Project with modules now, it's kinda awesome. I'm certainly never going back. The big compilers are also retroactively adding `import std` to CPP20, so support is widening. [1] https://gitlab.kitware.com/cmake/cmake/-/work_items/27706 https://gitlab.kitware.com/cmake/cmake/-/work_items/27706
- duped 7mo ago
  weird to blame build systems for a problem caused by the language
  - FrostKiwi 7mo ago
    You are of course right. It's just that Modules inherently put a lot of responsibility on the build system. Among those, but not limited to: a "module registry" wasn't standardized and is in the hands of the build system. Systems like ninja needs to know modules, which took time and then a stack further up systems like CMake needed to know modules, which took time. That's my answer to the parent "why are there so few modules projects". Because it took time for the ecosystem to catch up.
- nickelpro 7mo ago
  I wanted to ship import std in 4.3 but there are some major disagreements over where the std.o symbols are supposed to come from. Clang says "we don't need them", GCC says "we'll ship them in libstdc++", and MSVC says "you are supposed to provide them". I didn't know about that when I was working on finishing import std for CMake and accidentally broke a lot of code in the move to a native implementation of the module manifest format, so everything got reverted and put back into experimental.
  - FrostKiwi 7mo ago
    That's really interesting info, thanks!
bluGill 7mo ago
Modules need a lot of tooling. The tool vendors have been working hard on this for years. They have only just now said this is ready for early adopters. Most people are waiting for the early adopters to write the books on what best practices are - this needs a few more years of experience.
- duped 7mo ago
  if something so simple needs years of experience it's poorly designed
  - bluGill 7mo ago
    Modules are not simple. They sound simple only to people who have never digged into them.
    - duped 7mo ago
      I've worked extensively on module/import semantics for multiple products in my life. It is complex. However this complexity is on the implementer and not the user. If "best practices" need to be refined over years, it is poorly designed. This is not untrodden ground, other languages and ecosystems do sane things.
      - nickelpro 7mo ago
        This was considered during standardization. The feeling among tool developers at the time was it was "close enough" to Fortran modules to be mostly solvable. This was wrong, mostly because C++ compiler flag semantics are far more complicated than in Fortran, you live and you learn. The bones of most implementations is identical to Fortran though, we got a ~3 year head start on the work because of that. Ninja already had the dyndep patch ready to go from Fortran, CMake knew basically how to use scanners in build steps. However, it took longer than expected to get scanner support into the compilers, which then delayed everything downstream. Understanding when BMIs need to be rebuilt is still tricky. Packaging formats needed to be updated to understand module maps, etc, etc. Each step took a little longer than was initially hoped, and delays snowballed a bit. We'll get there.

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

by duped 7mo ago

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

You're not supposed to distribute the precompiled module file. You are supposed to distribute the source code of the module. Header-only projects are the best to convert to modules because you can put the implementation of a module in a "private module fragment" in that same file and make it invisible to users. That prevents the compile-time bloat many header-only dependencies add. It also avoids distributing a `.cpp` file that has to be compiled and linked separately, which is why so many projects are header-only.

duped 7mo ago
What I mean is, I have yet to see projects in the wild _use modules at all_.
- pjmlp 7mo ago
  Plenty of examples on Github, Microsoft has talks on how Office has migrated to modules, and the Vulkan updated tutorials from Khronos, have an optional learning path with modules.

FrostKiwi 7mo ago

It's the fault of built systems. CMake still doesn't support `import std` officially and undocumented things are done in the ecosystem [1] But once it works and you setup the new stuff, having started a new CPP26 Project with modules now, it's kinda awesome. I'm certainly never going back. The big compilers are also retroactively adding `import std` to CPP20, so support is widening. [1] https://gitlab.kitware.com/cmake/cmake/-/work_items/27706 https://gitlab.kitware.com/cmake/cmake/-/work_items/27706

duped 7mo ago
weird to blame build systems for a problem caused by the language
- FrostKiwi 7mo ago
  You are of course right. It's just that Modules inherently put a lot of responsibility on the build system. Among those, but not limited to: a "module registry" wasn't standardized and is in the hands of the build system. Systems like ninja needs to know modules, which took time and then a stack further up systems like CMake needed to know modules, which took time. That's my answer to the parent "why are there so few modules projects". Because it took time for the ecosystem to catch up.
nickelpro 7mo ago
I wanted to ship import std in 4.3 but there are some major disagreements over where the std.o symbols are supposed to come from. Clang says "we don't need them", GCC says "we'll ship them in libstdc++", and MSVC says "you are supposed to provide them". I didn't know about that when I was working on finishing import std for CMake and accidentally broke a lot of code in the move to a native implementation of the module manifest format, so everything got reverted and put back into experimental.
- FrostKiwi 7mo ago
  That's really interesting info, thanks!

bluGill 7mo ago

Modules need a lot of tooling. The tool vendors have been working hard on this for years. They have only just now said this is ready for early adopters. Most people are waiting for the early adopters to write the books on what best practices are - this needs a few more years of experience.

duped 7mo ago
if something so simple needs years of experience it's poorly designed
- bluGill 7mo ago
  Modules are not simple. They sound simple only to people who have never digged into them.
  - duped 7mo ago
    I've worked extensively on module/import semantics for multiple products in my life. It is complex. However this complexity is on the implementer and not the user. If "best practices" need to be refined over years, it is poorly designed. This is not untrodden ground, other languages and ecosystems do sane things.
    - nickelpro 7mo ago
      This was considered during standardization. The feeling among tool developers at the time was it was "close enough" to Fortran modules to be mostly solvable. This was wrong, mostly because C++ compiler flag semantics are far more complicated than in Fortran, you live and you learn. The bones of most implementations is identical to Fortran though, we got a ~3 year head start on the work because of that. Ninja already had the dyndep patch ready to go from Fortran, CMake knew basically how to use scanners in build steps. However, it took longer than expected to get scanner support into the compilers, which then delayed everything downstream. Understanding when BMIs need to be rebuilt is still tricky. Packaging formats needed to be updated to understand module maps, etc, etc. Each step took a little longer than was initially hoped, and delays snowballed a bit. We'll get there.