I'm going to take the contrarian view here, and say it's not clickbait.
I admit that I'm not a C++ expert, but naively I would never have expected clang-format to have any effect on my code. If you stopped and suggested header re-ordering to me my first thought would have been "I guess it must not do that. Maybe in practice header re-ordering doesn't actually matter with reasonable code?".
The title here doesn't describe the contents of the article, but it describes a very important consequence of it that C++ programmers should be aware of. It gives a specific example of the consequence. I'm ok with that.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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!)
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.
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.
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.
I admit that I'm not a C++ expert, but naively I would never have expected clang-format to have any effect on my code. If you stopped and suggested header re-ordering to me my first thought would have been "I guess it must not do that. Maybe in practice header re-ordering doesn't actually matter with reasonable code?".
The title here doesn't describe the contents of the article, but it describes a very important consequence of it that C++ programmers should be aware of. It gives a specific example of the consequence. I'm ok with that.