Clang Format Tanks Performance • Hacker News Board

Re: Clang Format Tanks Performance

#91

Post by pdimitar » Wed, Nov 20, 2019, 12:22 PM UTC

I may eat downvotes but here's an honest opinion nonetheless: this article shows almost exactly why I wouldn't touch C++ with a ten-foot pole still, after running away screaming from it 11-12 years ago.

Not saying it's an unique problem with C++'s tooling. I'm just saying that it has been my experience that one is much more likely to stumble upon such horrors while working with C++ as opposed to at least 7 other languages I worked with.

I'll take the slower Rust and Go and Elixir, thank you very much.

Don't take this as trash-talking, though. I simply want to get things done, not fight my environment.

Re: Clang Format Tanks Performance

#92

Post by LessDmesg » Wed, Nov 20, 2019, 12:49 PM UTC

Order of headers should not matter in any sane language. This just proves that C++ is not a sane language. Yet Bjarne Stroustrup keeps getting engineering awards! If I were king of programming languages, I would forbid any new lines of C++ to be brought into this world, and install mandatory programmes for rewriting legacy C++ code in sane languages.

Re: Clang Format Tanks Performance

#93

Post by intea » Wed, Nov 20, 2019, 12:54 PM UTC

LessDmesg wrote: post #92

Order of headers should not matter in any sane language. This just proves that C++ is not a sane language. Yet Bjarne Stroustrup keeps getting engineering awards! If I were king of programming languages, I would forbid any new lines of C++ to be brought into this world, and install mandatory programmes for rewriting legacy C++ code in sane languages.

But the root cause here lies with GCC or rather glibc and not the language? C++ is but a tool, just like every other language.

Re: Clang Format Tanks Performance

#94

Post by wffurr » Wed, Nov 20, 2019, 1:14 PM UTC

pdimitar wrote: post #91

I may eat downvotes but here's an honest opinion nonetheless: this article shows almost exactly why I wouldn't touch C++ with a ten-foot pole still, after running away screaming from it 11-12 years ago. Not saying it's an unique problem with C++'s tooling. I'm just saying that it has been my experience that one is much more likely to stumble upon such horrors while working with C++ as opposed to at least 7 other lang…

Rust is slower than C++?

Re: Clang Format Tanks Performance

#95

Post by devit » Wed, Nov 20, 2019, 1:19 PM UTC

pdimitar wrote: post #91

I may eat downvotes but here's an honest opinion nonetheless: this article shows almost exactly why I wouldn't touch C++ with a ten-foot pole still, after running away screaming from it 11-12 years ago. Not saying it's an unique problem with C++'s tooling. I'm just saying that it has been my experience that one is much more likely to stumble upon such horrors while working with C++ as opposed to at least 7 other lang…

While Go and Elixir might indeed be slower, Rust is designed to generate optimal code and offer zero-cost abstractions like C and C++ and I would expect it to do so in this case.

Re: Clang Format Tanks Performance

#96

Post by daemin » Wed, Nov 20, 2019, 1:20 PM UTC

pdimitar wrote: post #91

I may eat downvotes but here's an honest opinion nonetheless: this article shows almost exactly why I wouldn't touch C++ with a ten-foot pole still, after running away screaming from it 11-12 years ago. Not saying it's an unique problem with C++'s tooling. I'm just saying that it has been my experience that one is much more likely to stumble upon such horrors while working with C++ as opposed to at least 7 other lang…

If you want to just get things done then this sort of complexity wouldn't impact you in the slightest using C++. You could just write code without needing to know this information. This is something for people really needing to squeeze performance out of systems.

If you are looking for performance though, other languages have similar but different pitfalls and bits of esoteric knowledge that you need. Constructs that you should use or avoid, the layout of data in memory, when to run or prevent running of a GC, etc.

Re: Clang Format Tanks Performance

#97

Post by The_rationalist » Wed, Nov 20, 2019, 1:23 PM UTC

wffurr wrote: post #94

pdimitar wrote: post #91

I may eat downvotes but here's an honest opinion nonetheless: this article shows almost exactly why I wouldn't touch C++ with a ten-foot pole still, after running away screaming from it 11-12 years ago. Not saying it's an unique problem with C++'s tooling. I'm just saying that it has been my experience that one is much more likely to stumble upon such horrors while working with C++ as opposed to at least 7 other lang…

Rust is slower than C++?

Yes, at best 20% slower but can be far more slower if you hit worst case scenario.

Re: Clang Format Tanks Performance

#98

Post by devit » Wed, Nov 20, 2019, 1:24 PM UTC

intea wrote: post #93

LessDmesg wrote: post #92

Order of headers should not matter in any sane language. This just proves that C++ is not a sane language. Yet Bjarne Stroustrup keeps getting engineering awards! If I were king of programming languages, I would forbid any new lines of C++ to be brought into this world, and install mandatory programmes for rewriting legacy C++ code in sane languages.

But the root cause here lies with GCC or rather glibc and not the language? C++ is but a tool, just like every other language.

It likes with C++ not having a proper module system enforcing properties like module import order being irrelevant, and the glibc developers apparently failing to produce modules having such properties even if the language doesn't enforce it.

Re: Clang Format Tanks Performance

#99

Post by antoinealb » Wed, Nov 20, 2019, 1:24 PM UTC

OskarS wrote: post #83

TwoBit wrote: post #66

Earlier quoted context omitted.

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.

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

Re: Clang Format Tanks Performance

#100

Post by daemin » Wed, Nov 20, 2019, 1:34 PM UTC

defap wrote: post #68

dleslie wrote: post #60

Earlier quoted context omitted.

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.

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