6 ms·

I agree with most of that, although as the author I think it's still clickbait in the sense that: 1) clang-format is not really at fault here at all - the same

I agree with most of that, although as the author I think it's still clickbait in the sense that: 1) clang-format is not really at fault here at all - the same effect could have happened by adding a new header, reordering the headers manually, switching to a system with a different libc version or a different transitive header include tree, etc. 2) The title doesn't tell you wtf is up. You have to get at least half way through the post to figure that out. It's in the vein of "This one food could wreck your health" posts. That said, other aspects of clickbait are advertising or monetization to profit from the clicks. Except for the crypto mining bot I load into your browser, and which subsequently writes itself to your MBR or UEFI partition, I have no ads, affiliate links, patreon-alikes or other monetization vectors.

fizwhiz 7y ago
> Except for the crypto mining bot I load into your browser, and which subsequently writes itself to your MBR or UEFI partition Guess I won't be clicking on the link now.
- skrebbel 7y ago
  You're missing out. It's a great article, definitely worth all that monero.
TehCorwiz 7y ago
At least you’re forthcoming.
dleslie 7y ago
Of course clang format is at fault; reordering includes, even standard or system includes, will almost certainly effect how a complex C/C++ program compiles. That's just how it is, with the preprocessor and such. This is a _bad_ clang-format bug.
- TwoBit 7y ago
  That reordering is simply a feature of clang-format. Some coding standards require sorting includes alphabetically, possibly to avoid dupes and to make all include usage identical between source files.
  - jlarcombe 7y ago
    Indeed, and one reason I dislike sorting header includes alphanumerically is that it makes it easy for include-order-dependencies between them to creep in, as they're always used in the same relative order.
  - dleslie 7y ago
    In terms of C/C++ headers, that's like requiring all scopes have their expressions alphanumerically sorted. C/C++ headers are literal code-injection mechanisms; they aren't modifying a runtime environment by importing symbols, they inject code into the compilation unit.
  - OskarS 7y ago
    > Some coding standards require sorting includes alphabetically Those are some pretty dumb coding standards if that's true. (I mean, yeah, the original fault is with the C preprocessor and the fact that header order matters, but since we're stuck with that, having those kinds of coding standards is pretty darn silly!)
    - antoinealb 7y ago
      Well given that the order of the headers matter, wouldn't it make sense to have the coding standard specify one true include order ? That's the only way to have a deterministic result.
      - yifanl 7y ago
        That ties namespacing to performance, which just sounds horrible to deal with.
        7y ago
- sanxiyn 7y ago
  You can disable include reordering in clang-format. I don't think this is a bug, because I see the default here as a matter of policy decision.
  - HelloNurse 7y ago
    Given that reordering includes can have consequences, reordering includes blindly and casually like the OP is a form of Russian roulette: an order that works should be preserved until it stops working. The article describes false complexity caused by looking atr the issue in the wrong way: a "mysterious" performance problem, to be diagnosed, rather than the obvious consequence of a broken workflow that includes an extremely hazardous operation. In a voluntary header reordering experiment, all kinds of breakage could be detected with a trivial before and after comparison of compiled code.
- lilyball 7y ago
  Headers really shouldn’t be affecting each other. Header order shouldn’t matter. The fact that it does is arguably a bad design flaw in C/C++, although the C modules system pushed by Apple fixed this.
  - pdpi 7y ago
    Tooling developers don’t get to say “it shouldn’t matter”. It does matter, so the tools should account for this.
    - twic 7y ago
      clang-format does account for this: if you break your includes into groups with blank lines, clang-format will sort within but not across the groups. That is, clang-format offers a crude but simple API to the programmer to express which headers have order dependency, and which don't. Given that headers can have order dependency, it is sadly part of a C++ programmer's responsibility to know which do, just as it is their responsibility to know which functions have side-effects, etc. If they are using clang-format, it is then their responsibility to communicate this knowledge to it.
      - pdpi 7y ago
        Ok, that is a fairly unobtrusive way to describe dependencies, fair.
      - dleslie 7y ago
        The simplest way to communicate that this anti-feature is unwanted is to add this to your clang-format: SortIncludes: false
- BeeOnRope 7y ago
  Yes, but reordering the headers is usually safe. Having order-dependent behavior is a serious bug and should generally be fixed by the header authors. When you add a header do you usually carefully consider the interaction between the new header and all the exist ones? No, you just add it to the end of the existing list or at its sorted position? Yeah, me too. I agree that a formatting tool changing the behavior or performance is a serious issue, but I don't think it's a bug in clang-format in that I suspect it is deliberate design choice, and users can opt out if they want. Maybe the default could be changed or more visible warnings added to the documentation, but the real fix here needs to be in glibc.
  - umanwizard 7y ago
    No, I don’t normally think about header order, but if I’m unlucky enough to be getting some weird behavior based on header order, I think I’d be able to debug it before landing my change. I’d be pissed if the issue were introduced by a formatting pass.

fizwhiz 7y ago

> Except for the crypto mining bot I load into your browser, and which subsequently writes itself to your MBR or UEFI partition Guess I won't be clicking on the link now.

skrebbel 7y ago
You're missing out. It's a great article, definitely worth all that monero.

TehCorwiz 7y ago

At least you’re forthcoming.

dleslie 7y ago

Of course clang format is at fault; reordering includes, even standard or system includes, will almost certainly effect how a complex C/C++ program compiles. That's just how it is, with the preprocessor and such. This is a _bad_ clang-format bug.

TwoBit 7y ago
That reordering is simply a feature of clang-format. Some coding standards require sorting includes alphabetically, possibly to avoid dupes and to make all include usage identical between source files.
- jlarcombe 7y ago
  Indeed, and one reason I dislike sorting header includes alphanumerically is that it makes it easy for include-order-dependencies between them to creep in, as they're always used in the same relative order.
- dleslie 7y ago
  In terms of C/C++ headers, that's like requiring all scopes have their expressions alphanumerically sorted. C/C++ headers are literal code-injection mechanisms; they aren't modifying a runtime environment by importing symbols, they inject code into the compilation unit.
- OskarS 7y ago
  > Some coding standards require sorting includes alphabetically Those are some pretty dumb coding standards if that's true. (I mean, yeah, the original fault is with the C preprocessor and the fact that header order matters, but since we're stuck with that, having those kinds of coding standards is pretty darn silly!)
  - antoinealb 7y ago
    Well given that the order of the headers matter, wouldn't it make sense to have the coding standard specify one true include order ? That's the only way to have a deterministic result.
    - yifanl 7y ago
      That ties namespacing to performance, which just sounds horrible to deal with.
      - 7y ago
sanxiyn 7y ago
You can disable include reordering in clang-format. I don't think this is a bug, because I see the default here as a matter of policy decision.
- HelloNurse 7y ago
  Given that reordering includes can have consequences, reordering includes blindly and casually like the OP is a form of Russian roulette: an order that works should be preserved until it stops working. The article describes false complexity caused by looking atr the issue in the wrong way: a "mysterious" performance problem, to be diagnosed, rather than the obvious consequence of a broken workflow that includes an extremely hazardous operation. In a voluntary header reordering experiment, all kinds of breakage could be detected with a trivial before and after comparison of compiled code.
lilyball 7y ago
Headers really shouldn’t be affecting each other. Header order shouldn’t matter. The fact that it does is arguably a bad design flaw in C/C++, although the C modules system pushed by Apple fixed this.
- pdpi 7y ago
  Tooling developers don’t get to say “it shouldn’t matter”. It does matter, so the tools should account for this.
  - twic 7y ago
    clang-format does account for this: if you break your includes into groups with blank lines, clang-format will sort within but not across the groups. That is, clang-format offers a crude but simple API to the programmer to express which headers have order dependency, and which don't. Given that headers can have order dependency, it is sadly part of a C++ programmer's responsibility to know which do, just as it is their responsibility to know which functions have side-effects, etc. If they are using clang-format, it is then their responsibility to communicate this knowledge to it.
    - pdpi 7y ago
      Ok, that is a fairly unobtrusive way to describe dependencies, fair.
    - dleslie 7y ago
      The simplest way to communicate that this anti-feature is unwanted is to add this to your clang-format: SortIncludes: false
BeeOnRope 7y ago
Yes, but reordering the headers is usually safe. Having order-dependent behavior is a serious bug and should generally be fixed by the header authors. When you add a header do you usually carefully consider the interaction between the new header and all the exist ones? No, you just add it to the end of the existing list or at its sorted position? Yeah, me too. I agree that a formatting tool changing the behavior or performance is a serious issue, but I don't think it's a bug in clang-format in that I suspect it is deliberate design choice, and users can opt out if they want. Maybe the default could be changed or more visible warnings added to the documentation, but the real fix here needs to be in glibc.
- umanwizard 7y ago
  No, I don’t normally think about header order, but if I’m unlucky enough to be getting some weird behavior based on header order, I think I’d be able to debug it before landing my change. I’d be pissed if the issue were introduced by a formatting pass.