4 ms·

I'm super disappointed with modules. It's 2023, we've pushed out a new c++ standard since modules were standardised, and they're not usable. They're not suppor

I'm super disappointed with modules. It's 2023, we've pushed out a new c++ standard since modules were standardised, and they're not usable. They're not supported in cmake (unless you set CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API to 2182bf5c-ef0d-489a-91da-49dbc3090d2a if you're on the same version of cmake as I am). My experience is that no IDE's support them properly, so either you need to ifdef out for intellisense, or go back to no tooling support. The format breaks every update, so you can't distribute precompiled modules. Last but definitely not least, they're slower than headers. So, we've got a feature that we started talking about 11 years ago, standardised 3 years ago, not implemented fully, has no build system support, and is a downgrade over the existing solution from every real world use case I've seen. What a mess.

Davidbrcz 3y ago
That's the pinacle of C++ development !
shrimp_emoji 3y ago
It's still brand new, in C++ feature terms. I'm not surprised by, and would totally expect, all of the problems you cited.
- maccard 3y ago
  I think we've been talking about this and trying to implement it for long enough that "it's still new" stopped being an excuse 2 years ago.
vblanco 3y ago
They are not slower than headers. Ive been looking into it because modular STL is such a big win. On my little toy project i have .cpp files compiling in 0.05 seconds while doing import std. Downside is that at the moment you cant mix normal header STL with module STL in the same project (msvc), so its for cleanroom small projects only. I expect the second you can reliably use that almost everyone will switch overnight just from how fast of a speed boost it gives on the STL vs even precompiled headers.
- cwzwarich 3y ago
  The one way in which they are slower than headers is that they create longer dependency chains of translation units, whereas with headers you unlock more parallelism at the beginning of the build process, but much of it is duplicated work.
- klipt 3y ago
  I assume templates can only be partly preprocessed (parsed?) but not fully pre compiled, since final code depends on the template types?
  - vblanco 3y ago
    Yes, but template code is all on headers, so it gets parsed every single time its included on some compile unit. With modules this only happens once so its a huge speed upgrade in pretty much all cases.
    - moregrist 3y ago
      Whenever I’ve profiled compile times, parsing accounts for relatively little of the time, while the vast majority of the time is spent in the optimizer. So at least for my projects it’s a modest (maybe 10-20%) speed up, not the order of magnitude speed up I was hoping for. Thus C++ compile times will remain abysmal.
      - dagmx 3y ago
        For some template heavy code bases I’ve been in, going to PCH has cut my compile times to less than half. I assume modules will have a similar benefit in those particular repositories, but obviously YMMV
  - jcelerier 3y ago
    Depends on the compiler, clang is able to pre-instantiate templates and generate debug info as part of its pch system - (for instance most likely you have some std::vector<int> which can be instantiated somewhere in a transitively included header). In my projects enabling the relevant flags gave pretty nice speedups.
IAmLiterallyAB 3y ago
The progress is frustratingly slow. My understanding is GCC and Clang still haven't finished implementing them fully. Last I read they are still making significant changes, for example moving to the strong ownership model for symbols. Once they're done, hopefully the build system and IDE support will follow quickly. MSVC seems to be in much better shape.
- humanrebar 3y ago
  The progress is mostly unfunded. It's not that the work is especially slow (maybe it is a little?). Mostly it's that barely anyone is working on it. This is especially frustrating for organizations ostensibly paying vendors for high quality compilers.
  - Gibbon1 3y ago
    It's frustrating because consider how many hours are lost to compile times over the whole industry. I have no idea how many people are slopping C++ code. So lets just calculate it per 1000. Assume modules save an average of 10 minutes a day. 1000 X 250 days/year X 0.167 hours/day -> 41,666 hours a year per thousand coders. Or 21 man years. Yeah you'd think it'd be worth funding heavily.
    - kccqzy 3y ago
      When you use a good build system like Bazel modules do not save 10 minutes a day. The time saving is negligible. That's why large C++ shops do not care about modules and only volunteers are working on them.
      - maccard 3y ago
        Not everyone uses bazel. I would wager that a vanishingly small amount of people use bazel. If people using other things was enough to not let things be standardized we wouldn't have asio, ranges, fmt. Precompiled headers also exist, so why would we standardise modules?
aseipp 3y ago
Module support will be stabilized in CMake 3.28, actually: https://www.reddit.com/r/cpp/comments/16y9qv2/cmake_c_modules_support_in_328/ https://www.reddit.com/r/cpp/comments/16y9qv2/cmake_c_module... The other points (mainly integration points) are definitely valid though.
- maccard 3y ago
  That's really great to hear. Having proper build system support will finally let us use this in anger and report actual issues upstream.
  - mathstuf 3y ago
    Please also report relevant issues to CMake itself. We can't fix what we don't hear about :) . FD: CMake developer.
    - maccard 3y ago
      I absolutely will. Im usually not cutting edge enough to catch stuff, by the time I find it it's usually already reported.
humanrebar 3y ago
> I'm super disappointed with modules. It's 2023, we've pushed out a new c++ standard since modules were standardised, and they're not usable. Important question: Who are you disappointed in? Keep in mind that the ISO committee does not employ engineers and for international treaty reasons, it reasonably cannot. Point being, who should be doing this work? Are you talking to them about your expectations? Are you providing actual support to implementations that are public goods (i.e., open source compilers)?
- david2ndaccount 3y ago
  The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice.
  - deleted 3y ago
    [deleted]
  - rewmie 3y ago
    > The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice. How do you expect to standardize a feature that does not exist yet but the whole community is demanding? It sounds like the C++ standardization committee designed a feature following a process where all stakeholders had a say. Is this worse than being force-fed a vendor-specific solution?
    - david2ndaccount 3y ago
      I do not expect standardization of features that do not exist.
      - rewmie 3y ago
        > I do not expect standardization of features that do not exist. But that makes absolutely no sense, doesn't it? I mean, think about it for a moment. Specifying a standard behavior is not about picking a flawed winner from a list of ad-hoc implementation or settle with the least common denominator. Specifying a standard behavior is about providing the best possible solution that meets the design requirements following the input from the whole community.
IshKebab 3y ago
My feeling is that the desire for it has somewhat waned because so many people that care about the elegance of programming languages and use C++ have just moved to Rust. There are still plenty of people using C++ of course, but it certainly feels like more of a dead end than it did before Rust. Why bother putting a mountain of effort into maybe slightly improving it when in 10-20 years you won't be using it anyway?
- deterministic 3y ago
  The number of Rust developers is a drop in the ocean compared with C++ developers. There are more than 5 million C++ developers out there starting new C++ projects every single day. I am one of them.
  - steveklabnik 3y ago
    Not that I disagree that there are a large number of C++ programmers out there, but where did you get that number?
  - IshKebab 3y ago
    Yeah obviously that's true now because C++ has been around for literally decades and had basically 0 competition for all that time.
    - deterministic 3y ago
      And it will continue to be true for a very long time since the world runs on software written in C and C++ and that needs to be maintained and improved.
baybal2 3y ago
[dead]
matheusmoreira 3y ago
> The format breaks every update, so you can't distribute precompiled modules. When will they fix this? People keep using C to this day because these unstable binary interfaces make it so no one can reuse software. Can't write a library in almost any other language and expect it to just work. To this day, C is the lowest common denominator of software because of stuff like this.
- mathstuf 3y ago
  Unlikely to be fixed. The module files are basically AST dumps and no compiler keeps that stable over time. Even flag selections make incompatible BMIs. So if one TU uses C++20 and another uses C++23, they'll each need their own BMI of anything they import. FD: CMake developer that implemented the modules support
  - maccard 3y ago
    If module files are pretty much memory dumps that makes it all the more frustrating that it's taken this long, given thats what precompiled headers essentially are.
    - mathstuf 3y ago
      There are new rules about "reachability" and "module linkage". Not to mention things like methods defined within the class declaration are no longer as-if `inline` when within a module. It's not just "a faster preprocessor" mode; there are real rules associated with module boundaries.
- leni536 3y ago
  C++ has stable binary interfaces just like C.
  - matheusmoreira 3y ago
    I've seen compiled C++ code turn out to be incompatible with code produced by different versions of the same compiler. There is no way this is stable.

Davidbrcz 3y ago

That's the pinacle of C++ development !

shrimp_emoji 3y ago

It's still brand new, in C++ feature terms. I'm not surprised by, and would totally expect, all of the problems you cited.

maccard 3y ago
I think we've been talking about this and trying to implement it for long enough that "it's still new" stopped being an excuse 2 years ago.

vblanco 3y ago

They are not slower than headers. Ive been looking into it because modular STL is such a big win. On my little toy project i have .cpp files compiling in 0.05 seconds while doing import std. Downside is that at the moment you cant mix normal header STL with module STL in the same project (msvc), so its for cleanroom small projects only. I expect the second you can reliably use that almost everyone will switch overnight just from how fast of a speed boost it gives on the STL vs even precompiled headers.

cwzwarich 3y ago
The one way in which they are slower than headers is that they create longer dependency chains of translation units, whereas with headers you unlock more parallelism at the beginning of the build process, but much of it is duplicated work.
klipt 3y ago
I assume templates can only be partly preprocessed (parsed?) but not fully pre compiled, since final code depends on the template types?
- vblanco 3y ago
  Yes, but template code is all on headers, so it gets parsed every single time its included on some compile unit. With modules this only happens once so its a huge speed upgrade in pretty much all cases.
  - moregrist 3y ago
    Whenever I’ve profiled compile times, parsing accounts for relatively little of the time, while the vast majority of the time is spent in the optimizer. So at least for my projects it’s a modest (maybe 10-20%) speed up, not the order of magnitude speed up I was hoping for. Thus C++ compile times will remain abysmal.
    - dagmx 3y ago
      For some template heavy code bases I’ve been in, going to PCH has cut my compile times to less than half. I assume modules will have a similar benefit in those particular repositories, but obviously YMMV
- jcelerier 3y ago
  Depends on the compiler, clang is able to pre-instantiate templates and generate debug info as part of its pch system - (for instance most likely you have some std::vector<int> which can be instantiated somewhere in a transitively included header). In my projects enabling the relevant flags gave pretty nice speedups.

IAmLiterallyAB 3y ago

The progress is frustratingly slow. My understanding is GCC and Clang still haven't finished implementing them fully. Last I read they are still making significant changes, for example moving to the strong ownership model for symbols. Once they're done, hopefully the build system and IDE support will follow quickly. MSVC seems to be in much better shape.

humanrebar 3y ago
The progress is mostly unfunded. It's not that the work is especially slow (maybe it is a little?). Mostly it's that barely anyone is working on it. This is especially frustrating for organizations ostensibly paying vendors for high quality compilers.
- Gibbon1 3y ago
  It's frustrating because consider how many hours are lost to compile times over the whole industry. I have no idea how many people are slopping C++ code. So lets just calculate it per 1000. Assume modules save an average of 10 minutes a day. 1000 X 250 days/year X 0.167 hours/day -> 41,666 hours a year per thousand coders. Or 21 man years. Yeah you'd think it'd be worth funding heavily.
  - kccqzy 3y ago
    When you use a good build system like Bazel modules do not save 10 minutes a day. The time saving is negligible. That's why large C++ shops do not care about modules and only volunteers are working on them.
    - maccard 3y ago
      Not everyone uses bazel. I would wager that a vanishingly small amount of people use bazel. If people using other things was enough to not let things be standardized we wouldn't have asio, ranges, fmt. Precompiled headers also exist, so why would we standardise modules?

aseipp 3y ago

Module support will be stabilized in CMake 3.28, actually: https://www.reddit.com/r/cpp/comments/16y9qv2/cmake_c_modules_support_in_328/ https://www.reddit.com/r/cpp/comments/16y9qv2/cmake_c_module... The other points (mainly integration points) are definitely valid though.

maccard 3y ago
That's really great to hear. Having proper build system support will finally let us use this in anger and report actual issues upstream.
- mathstuf 3y ago
  Please also report relevant issues to CMake itself. We can't fix what we don't hear about :) . FD: CMake developer.
  - maccard 3y ago
    I absolutely will. Im usually not cutting edge enough to catch stuff, by the time I find it it's usually already reported.

humanrebar 3y ago

> I'm super disappointed with modules. It's 2023, we've pushed out a new c++ standard since modules were standardised, and they're not usable. Important question: Who are you disappointed in? Keep in mind that the ISO committee does not employ engineers and for international treaty reasons, it reasonably cannot. Point being, who should be doing this work? Are you talking to them about your expectations? Are you providing actual support to implementations that are public goods (i.e., open source compilers)?

david2ndaccount 3y ago
The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice.
- deleted 3y ago
  [deleted]
- rewmie 3y ago
  > The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice. How do you expect to standardize a feature that does not exist yet but the whole community is demanding? It sounds like the C++ standardization committee designed a feature following a process where all stakeholders had a say. Is this worse than being force-fed a vendor-specific solution?
  - david2ndaccount 3y ago
    I do not expect standardization of features that do not exist.
    - rewmie 3y ago
      > I do not expect standardization of features that do not exist. But that makes absolutely no sense, doesn't it? I mean, think about it for a moment. Specifying a standard behavior is not about picking a flawed winner from a list of ad-hoc implementation or settle with the least common denominator. Specifying a standard behavior is about providing the best possible solution that meets the design requirements following the input from the whole community.

IshKebab 3y ago

My feeling is that the desire for it has somewhat waned because so many people that care about the elegance of programming languages and use C++ have just moved to Rust. There are still plenty of people using C++ of course, but it certainly feels like more of a dead end than it did before Rust. Why bother putting a mountain of effort into maybe slightly improving it when in 10-20 years you won't be using it anyway?

deterministic 3y ago
The number of Rust developers is a drop in the ocean compared with C++ developers. There are more than 5 million C++ developers out there starting new C++ projects every single day. I am one of them.
- steveklabnik 3y ago
  Not that I disagree that there are a large number of C++ programmers out there, but where did you get that number?
- IshKebab 3y ago
  Yeah obviously that's true now because C++ has been around for literally decades and had basically 0 competition for all that time.
  - deterministic 3y ago
    And it will continue to be true for a very long time since the world runs on software written in C and C++ and that needs to be maintained and improved.

baybal2 3y ago

[dead]

matheusmoreira 3y ago

> The format breaks every update, so you can't distribute precompiled modules. When will they fix this? People keep using C to this day because these unstable binary interfaces make it so no one can reuse software. Can't write a library in almost any other language and expect it to just work. To this day, C is the lowest common denominator of software because of stuff like this.

mathstuf 3y ago
Unlikely to be fixed. The module files are basically AST dumps and no compiler keeps that stable over time. Even flag selections make incompatible BMIs. So if one TU uses C++20 and another uses C++23, they'll each need their own BMI of anything they import. FD: CMake developer that implemented the modules support
- maccard 3y ago
  If module files are pretty much memory dumps that makes it all the more frustrating that it's taken this long, given thats what precompiled headers essentially are.
  - mathstuf 3y ago
    There are new rules about "reachability" and "module linkage". Not to mention things like methods defined within the class declaration are no longer as-if `inline` when within a module. It's not just "a faster preprocessor" mode; there are real rules associated with module boundaries.
leni536 3y ago
C++ has stable binary interfaces just like C.
- matheusmoreira 3y ago
  I've seen compiled C++ code turn out to be incompatible with code produced by different versions of the same compiler. There is no way this is stable.