5 ms·

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. Th

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.
      - antoinealb 7y ago
        Of course, the bug is horrible. But given that those type of bugs exist, having a fixed ordering of include statements seem like the least painful way to go.
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.

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.
    - antoinealb 7y ago
      Of course, the bug is horrible. But given that those type of bugs exist, having a fixed ordering of include statements seem like the least painful way to go.

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.