Hacker News Reader

Comment by JonathonW | Hacker News Reader

Just to make sure I'm understanding this correctly: the performance issue you found actually amounts to include-order dependent behavior in GCC and glibc; clang doesn't really have anything to do with anything here except that you used its code formatter to sort your include statements.

If that's the case, the clickbait-y headline's bordering on useless, since the performance differences here have nothing to do with clang itself-- you'd see the same results if you had ordered your includes the same way by hand.

View on HN

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.

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.

No, the headline pretty clearly states "Clang Format". I've used clang-format on MSVC codebases, and imagine there are some who use it with GCC (say, for instance, the author). It's still the best C++ formatter, as far as I know, and is compiler-independent.

It's basically the gorilla in the space, and it's good.

There is no gcc equivalent. In any case there no 1:1 relationship between formatters anyways: you might compiler you codebase with N compilers, but you'll only have one formatter unless you are insane. So my codebases are not "gcc" or "clang" codebases, but basically "linux" codebases - but the formatter is always clang-format.

It would actually be interesting to see if this phenomenon happens with clang, which has its own implementation of the standard library. And perhaps with musl libc or some such.

Clang has its own libc++ implementation, but I think clang still uses the system libc and associated headers?

Yes, i think so too. So a different <algorithm>, but the same <ctype.h>.

The crucial __NO_CTYPE define is in <bits/os_defines.h>, which is part of the GCC paraphernalia. I don't know if clang's stdlib would also have to end up defining it.

Reply on news.ycombinator.com