4 ms·

They're straightforward and easy to reason about. Textual inclusion also allows a number of things modules do not. The main disadvantage that they have, that

They're straightforward and easy to reason about. Textual inclusion also allows a number of things modules do not. The main disadvantage that they have, that they're stateful, is also true of module systems in many languages (e.g. python).

dagmx 3y ago
I greatly disagree with “easier to reason about” Maybe in a clean, smaller codebase with minimal dependencies. But the textual inclusion means that including one header can suddenly break previously compiling code. Unless that header is completely inclusive, that can mean a while of chasing down transitive headers till you find the problematic one.
- mgaunard 3y ago
  The semantics are literally "it's the same as copy-pasting it where it's used". It doesn't get simpler than this. There are much more things going on in the module system that you'd have to know about if you care about what's actually going on.
  - dagmx 3y ago
    The module system doesn’t have side effects on inclusion, whereas headers do. So again, maybe if you have a smaller, cleaner or dependency free codebase, then it’s not an issue. But in any codebase of major scale or legacy, headers can introduce several issues that aren’t possible with the module interface.
    - mgaunard 3y ago
      The side-effects are merely the rules of C++, that you already know by virtue of writing C++.
      - dagmx 3y ago
        I feel like you’re talking past any of the caveats I’ve mentioned twice. I have no interest in belabouring the point with someone who’s clearly ignoring what’s being written. Have a good day.
  - maccard 3y ago
    You're really burying the lede here. Headers are literal copy paste, and are entirely different. Anyone who has ever had to define WIN32_LEAN_AND_MEAN knows that there's _way_ more going on here.
    - dagmx 3y ago
      This exactly, thank you. Sometimes you can’t untangle the defines in another header and they infect your own. Modules are a nice barrier to guard against side effects.
      - mathstuf 3y ago
        Yes, the number of times I've had a `LoadLibrary` function name conflict with `windows.h`'s `A`/`W` suffix-switching or had to deal with X11's `#define Status int` "typedef" mucking with completely unrelated code is…sad.
        mgaunard 3y ago
        Just don't include those in headers.
        maccard 3y ago
        That's not possible. Windows.h is a requirement for anyone working on Windows. Various standard library implementations make use of macros to implement debug-only assertions, or bounds checks in containers.
        mgaunard 3y ago
        Don't include it in headers = only include it in a .cpp file.
        mathstuf 3y ago
        Because `void*` to pass `HANDLE` around is better how? Maybe if you're able to hermetically seal off platform-specific bits, but usually you'll have two parts that want to talk about Windows API types across their call boundaries…

dagmx 3y ago

I greatly disagree with “easier to reason about” Maybe in a clean, smaller codebase with minimal dependencies. But the textual inclusion means that including one header can suddenly break previously compiling code. Unless that header is completely inclusive, that can mean a while of chasing down transitive headers till you find the problematic one.

mgaunard 3y ago
The semantics are literally "it's the same as copy-pasting it where it's used". It doesn't get simpler than this. There are much more things going on in the module system that you'd have to know about if you care about what's actually going on.
- dagmx 3y ago
  The module system doesn’t have side effects on inclusion, whereas headers do. So again, maybe if you have a smaller, cleaner or dependency free codebase, then it’s not an issue. But in any codebase of major scale or legacy, headers can introduce several issues that aren’t possible with the module interface.
  - mgaunard 3y ago
    The side-effects are merely the rules of C++, that you already know by virtue of writing C++.
    - dagmx 3y ago
      I feel like you’re talking past any of the caveats I’ve mentioned twice. I have no interest in belabouring the point with someone who’s clearly ignoring what’s being written. Have a good day.
- maccard 3y ago
  You're really burying the lede here. Headers are literal copy paste, and are entirely different. Anyone who has ever had to define WIN32_LEAN_AND_MEAN knows that there's _way_ more going on here.
  - dagmx 3y ago
    This exactly, thank you. Sometimes you can’t untangle the defines in another header and they infect your own. Modules are a nice barrier to guard against side effects.
    - mathstuf 3y ago
      Yes, the number of times I've had a `LoadLibrary` function name conflict with `windows.h`'s `A`/`W` suffix-switching or had to deal with X11's `#define Status int` "typedef" mucking with completely unrelated code is…sad.
      - mgaunard 3y ago
        Just don't include those in headers.
        maccard 3y ago
        That's not possible. Windows.h is a requirement for anyone working on Windows. Various standard library implementations make use of macros to implement debug-only assertions, or bounds checks in containers.
        mgaunard 3y ago
        Don't include it in headers = only include it in a .cpp file.
        mathstuf 3y ago
        Because `void*` to pass `HANDLE` around is better how? Maybe if you're able to hermetically seal off platform-specific bits, but usually you'll have two parts that want to talk about Windows API types across their call boundaries…