Hacker News Reader

Comment by BeeOnRope | Hacker News Reader

I'm talking about clang-format, a formatting tool for C and C++ code, which has nothing to do with compiling your code with clang. You can use it with any compiler.

That said, the title is still a lie in that clang-format is not really at a fault here at all: clang-format triggered the issue on my codebase, by sorting header files, and this in turn triggered a libc performance issue.

So as I initially say it, a commit which purely clang-format 'd my codebase caused a massive regression - but the full story is doesn't implicate clang-format at all, really.

View on HN

The title would be a /little/ clearer with a dash between Clang and format.

Or "header inclusion order may affect performance." If someone points to this as a reason not to use clang-format...

Good point, I put a hyphen a few places but not everywhere nor in the title. It seems hyphen is definitely the standard though.

Fixed now [1], although the HN title will remain hyphen-free free I guess.

---

[1] https://github.com/travisdowns/travisdowns.github.io/commit/...

clang-format reordering includes is a terrible behaviour. It would break many C/C++ projects.

It's optional, although it's enabled by default in the LLVM and Chromium styles.

That's a bizarre optional feature to have; it's tantamount to having a "blindly reorder logic" function that sorts your source alphanumerically.

Not really too bizarre. Header files should include or declare everything they need; they should not introduce include-order dependencies. Listing your includes in lexicographic order is a good way to enforce header completeness.

It is by convention that C/C++ headers rely on preprocessor state to determine what blocks to reveal, macros to use, et al.

It is quite common to have an auto-generated configuration header, for instance; or a precompiled header; or optional headers that, when present, mutate the behaviour of other headers.

Every time you run a configure script for a C project there's a good chance you're interacting with code in this way.

clang-format still allows some ordering when the SortIncludes feature is enabled. Search for IncludeBlocks in https://clang.llvm.org/docs/ClangFormatStyleOptions.html

Yeah, and if you want to use clang-format include reordering in such a project, you should read the docs for clang-format's "IncludeCategories". It allows you to separate your includes into blocks by providing regexes and associated priorities. Alphabetic sorting is done only within a block.

It's not like clang-format was written by idiots who never used the language before. Maybe read up on what the tool actually does before you get all mad at them?

I'm not mad?

I think it's a harmful anti-feature that's worthy of criticism.

One other ordering I've encountered which helps remove errors is to list the headers in reverse generic order. Meaning that you go from the most specific header files to the least specific. So <algorithm> and <windows.h> would be getting included last.

This helps ensure that your specific project level header files have all the necessary forward declares and includes to be a fully functioning and complete header.

I also sort my includes this way. The trouble is, determining how generic an include (inclusion?) is is a fuzzy problem. Sometimes I get stuck trying to figure out which header is more abstract, and at times I've run into side effects like this even with reverse generic sorting.

Yeah, this header sorting is only meant to be a tool to help craft header files which are independent. If that's not your project structure then you can use whatever sorting you want.

In the end though you'll have to make a decision on how to sort the projects and which one is more or less specific than another. Kind of like deciding to just sort by pointer address if all else is equal.

Reply on news.ycombinator.com