5 ms·

As expected modules are relegated to some later time ("will be its own experiment")

by dureuill 4y ago

pjmlp 4y ago
Thanks clang lagging behind ISO C++, you can use them today on Visual Studio 2022.
- mike_hock 4y ago
  Can't blame them. Modules are Microsoft sabotaging the standard so they can be the only conforming implementation, just like with the Office .doc format. Modules are unimplementable shite. They would be great if this was the first iteration of the language, but they're a nightmare to fit into the existing ecosystem. If they get support in open source compilers, we can look forward to at least one or two decades of a mixed modules/headers mess in open source projects.
  - pjmlp 4y ago
    Yet, somehow the GCC folks manage to keep improving their modules support, slow and steady. If they were unimplementable, there wouldn't exist already two major C++ compilers supporting them to some degree. It is only clang with their module maps pseudo concept that keeps lagging, that and plenty of other C++20 features.
    - mike_hock 4y ago
      Implementable by compilers, sure. Implementable by the ecosystem at large, yes, over the course of several decades. Edit: Also, module support better be 100% binary compatible between GCC and Clang, or it's worse than complete garbage.
      - pjmlp 4y ago
        As if you could expect any kind of ABI compatibility between GCC and clang binary libraries today, and apparently it doesn't make them a complete garbage, go figure.
        leni536 4y ago
        umm, you can edit: to elaborate both g++ and clang++ implement the Itanium C++ ABI[1]. You might get binary incompatibility by mixing standard libraries, so just don't do that. [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html https://itanium-cxx-abi.github.io/cxx-abi/abi.html
        pjmlp 4y ago
        Which is exactly what happens when using shared objects. Additionally the C++ ABI doesn't tell anything about how each binary library was compiled regarding compiler and linker switches that affect runtime behaviour.
        leni536 4y ago
        > Which is exactly what happens when using shared objects. Right. This has nothing to do to gcc, clang and even C++ though. I would be surprised if you could freely link C shared objects linked to different libc implementations. On most Linux distros both gcc and clang link to libstdc++, so everything works out of the box. I imagine this is not the case for MacOS xcode and gcc from homebrew.
        int_19h 4y ago
        Standard libraries is what makes most of C++. (Like, literally, going by the size of the language spec.)
        leni536 4y ago
        And the same applies to C and libc.
  - karterk 4y ago
    What are some ways in which they are bad/broken?
    - dureuill 4y ago
      modules were my #1 wanted feature in C++, but they are very disappointing to me: - they allow `.` in their names to signify hierarchy, but have no built-in notion of hierarchy or submodule. This means possible error messages will have to be suboptimal - they are orthogonal to namespaces, meaning if you have a module `foo.bar` any identifier it will export will be in the global namespace unless you put it in the `foo::bar` namespace in the `foo.bar` module file. As a user this means that I can import a `foo.bar` module and expect symbols to be imported in any namespace. - btw, what happens if different modules import the same name? I'll let you guess:-D. Modules were the chance to eliminate this kind of issues by eliminating the notion of shared namespaces, but oh well... - modules have interface units, implementation units, partitions, interface partition and implementation partition. There must be exactly one non partition interface unit, called the primary module interface. Instead of, you know, just having modules and submodules files like all modern module systems in existence. - Modules add new and fun ways to get ill-formed, no diagnostic required programs. Such as not re-exporting all interface partitions. I really hoped that modules were the chance of introducing a simpler compilation model for C++. I'm not pleased with the result. Some references: [0]: https://vector-of-bool.github.io/2019/01/27/modules-doa.html https://vector-of-bool.github.io/2019/01/27/modules-doa.html [1]: https://vector-of-bool.github.io/2019/03/10/modules-1.html https://vector-of-bool.github.io/2019/03/10/modules-1.html
      - tele_ski 4y ago
        Yikes, I was so excited for modules back when I was still writing C++17 and a bit of early 20. Sad they have so many problems with them and/or are just plain not implemented still. Honestly I'm happy I'ved moved on from the language
      - int_19h 4y ago
        Popular languages that went for strict 1:1 mapping between modules and filesystem, like Java and Python, often end up moving away from it, or at least adding various hacks (e.g. the way you can split submodules across packages in Python).
- JonChesterfield 4y ago
  Clang had modules ages ago. Still does I think, but not the same thing as was standardised.
  - pjmlp 4y ago
    What it has are pseudo modules implementated via configuration files called module maps, completely unrelated to how C++20 modules work.

As expected modules are relegated to some later time ("will be its own experiment")

pjmlp 4y ago

Thanks clang lagging behind ISO C++, you can use them today on Visual Studio 2022.

mike_hock 4y ago
Can't blame them. Modules are Microsoft sabotaging the standard so they can be the only conforming implementation, just like with the Office .doc format. Modules are unimplementable shite. They would be great if this was the first iteration of the language, but they're a nightmare to fit into the existing ecosystem. If they get support in open source compilers, we can look forward to at least one or two decades of a mixed modules/headers mess in open source projects.
- pjmlp 4y ago
  Yet, somehow the GCC folks manage to keep improving their modules support, slow and steady. If they were unimplementable, there wouldn't exist already two major C++ compilers supporting them to some degree. It is only clang with their module maps pseudo concept that keeps lagging, that and plenty of other C++20 features.
  - mike_hock 4y ago
    Implementable by compilers, sure. Implementable by the ecosystem at large, yes, over the course of several decades. Edit: Also, module support better be 100% binary compatible between GCC and Clang, or it's worse than complete garbage.
    - pjmlp 4y ago
      As if you could expect any kind of ABI compatibility between GCC and clang binary libraries today, and apparently it doesn't make them a complete garbage, go figure.
      - leni536 4y ago
        umm, you can edit: to elaborate both g++ and clang++ implement the Itanium C++ ABI[1]. You might get binary incompatibility by mixing standard libraries, so just don't do that. [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html https://itanium-cxx-abi.github.io/cxx-abi/abi.html
        pjmlp 4y ago
        Which is exactly what happens when using shared objects. Additionally the C++ ABI doesn't tell anything about how each binary library was compiled regarding compiler and linker switches that affect runtime behaviour.
        leni536 4y ago
        > Which is exactly what happens when using shared objects. Right. This has nothing to do to gcc, clang and even C++ though. I would be surprised if you could freely link C shared objects linked to different libc implementations. On most Linux distros both gcc and clang link to libstdc++, so everything works out of the box. I imagine this is not the case for MacOS xcode and gcc from homebrew.
        int_19h 4y ago
        Standard libraries is what makes most of C++. (Like, literally, going by the size of the language spec.)
        leni536 4y ago
        And the same applies to C and libc.
- karterk 4y ago
  What are some ways in which they are bad/broken?
  - dureuill 4y ago
    modules were my #1 wanted feature in C++, but they are very disappointing to me: - they allow `.` in their names to signify hierarchy, but have no built-in notion of hierarchy or submodule. This means possible error messages will have to be suboptimal - they are orthogonal to namespaces, meaning if you have a module `foo.bar` any identifier it will export will be in the global namespace unless you put it in the `foo::bar` namespace in the `foo.bar` module file. As a user this means that I can import a `foo.bar` module and expect symbols to be imported in any namespace. - btw, what happens if different modules import the same name? I'll let you guess:-D. Modules were the chance to eliminate this kind of issues by eliminating the notion of shared namespaces, but oh well... - modules have interface units, implementation units, partitions, interface partition and implementation partition. There must be exactly one non partition interface unit, called the primary module interface. Instead of, you know, just having modules and submodules files like all modern module systems in existence. - Modules add new and fun ways to get ill-formed, no diagnostic required programs. Such as not re-exporting all interface partitions. I really hoped that modules were the chance of introducing a simpler compilation model for C++. I'm not pleased with the result. Some references: [0]: https://vector-of-bool.github.io/2019/01/27/modules-doa.html https://vector-of-bool.github.io/2019/01/27/modules-doa.html [1]: https://vector-of-bool.github.io/2019/03/10/modules-1.html https://vector-of-bool.github.io/2019/03/10/modules-1.html
    - tele_ski 4y ago
      Yikes, I was so excited for modules back when I was still writing C++17 and a bit of early 20. Sad they have so many problems with them and/or are just plain not implemented still. Honestly I'm happy I'ved moved on from the language
    - int_19h 4y ago
      Popular languages that went for strict 1:1 mapping between modules and filesystem, like Java and Python, often end up moving away from it, or at least adding various hacks (e.g. the way you can split submodules across packages in Python).
JonChesterfield 4y ago
Clang had modules ages ago. Still does I think, but not the same thing as was standardised.
- pjmlp 4y ago
  What it has are pseudo modules implementated via configuration files called module maps, completely unrelated to how C++20 modules work.