4 ms·
Could be, but I feel it would equally dishonest? This really has nothing to do with clang-format: I only mention that once (twice with an update: where clang f
by BeeOnRope 7y ago
Could be, but I feel it would equally dishonest?
This really has nothing to do with clang-format: I only mention that once (twice with an update: where clang format actually helps because it reorders stdlib.h after ctype.h) - it's all about header include order.
- mipmap04 7y agoMaybe someone should make a tool that randomly reorders your header includes until optimal performance is found.
- emmelaich 7y agoI think clang-format is definitely relevant; the take-away here is that no formatter should change the order of includes. I was wondering about this only yesterday - tidying up some C++ and C code. I don't remember any standard that says it's OK to re-order headers, and clearly it can matter a lot.
- BeeOnRope 7y agoThat wouldn't be my take away. My takeway would be anything that changes in semantics or performance due to header includes should be considered a bug by the (possibly joint) writers of the involved headers. clang-format is an innocent victim here. Maybe I should make that clearer.
- flukus 7y agoClang isn't the root cause, but as a (relatively) new tool in an existing ecosystem it needs to work with the existing ecosystem and not some imaginary idealistic world.
- mypalmike 7y agoChanging semantics due to header order is considered a feature in C/C++. If you aren't willing to waste hours working through esoteric header issues, you just aren't tough enough.