Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++20, How Hard Could It Be

docs.google.com

Post reply on HN
Print view View original

131–140 of 444 posts

Re: C++20, How Hard Could It Be

#131

Post by pjmlp »

IshKebab wrote: post #35
pornel wrote: post #8

Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.

It generally does although they have made technically breaking changes in the past (e.g. `auto`). This is the first release I've used where they broke something in actual code I use because of the comparison operator changes. However it was easy to fix and actually it was because whoever wrote it did it wrong. Google also found a breakage that was hiding a bug. So maybe their new stance is "only break incorrect code"…

They also broke the code of the few users that made use of exception specifications.

Re: C++20, How Hard Could It Be

#132

Post by kadoban »

philliphaydon wrote: post #126

This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11. But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.

If you're writing the same code, almost certainly not.

The only way there would be would be if the compiler either can't optimize something as well because the lang changes requirements (this seems unlikely), or if they have bugs or inefficiencies because they haven't spent much time on the new standard.

If you're using new stuff from the new standard, they could be slower or faster or undecidable, really depends.

Re: C++20, How Hard Could It Be

#133

Post by tomohawk »

I mentioned to a former team mate who has been doing c++ for 30 years or so that he might take a look at go or rust for a lot of the things they're doing.

His response was, "I already have a new language to learn: c++".

Re: C++20, How Hard Could It Be

#134

Post by scatters »

raverbashing wrote: post #27

So, it seems most problems are C++ making things extra bureaucratic and annoying. Cool The "pre/post increment of volatiles is deprecated" sounds like a huge pain. I can't imagine a worse waste of developer time than fixing such a minor thing (and to be fair C allowing both a++ / ++a should never have existed)

That's been undeprecated in C++23. It's mildly embarrassing, but it shows the process works.

Re: C++20, How Hard Could It Be

#135

Post by cletus »

arinlen wrote: post #128
cletus wrote: post #116

Just a note but I'm fairly certain this is purely from the perspective of Google Chrome, meaning it excludes google3 (Google's repo for nearly all Google services). I don't know this for a fact but I suspect it's the case. I only bring it up because google3 C++ is (or was; it's now been years since I've done this directly) a very different beast. It was notionally compliant with recent standards but a very restrictiv…

> The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. I feel you're embelishing too much your personal feeling of horror. The C++20 standard doc is a hair smaller than 1900 pages, but the complete core language is specified in the first 460 pages, of which around 100 are dedicated to templates. Thus around 1400 pages of a 1900page doc are dedicated to specify librar…

You could focus on those 460 pages but I'll raise 2 points:

1. There's still a lot of complexity and ambiguity you can fit in 460 pages. This presentation notes one example of decrement operators on volatile variables being deprecated because the behaviour was undefined; and

2. Can you really separate the standard library from the language at this point? Things like move semantics depend on std. Does anyone actually use C++ without any of the standard library?

Re: C++20, How Hard Could It Be

#137

Post by qsdf38100 »

yakubin wrote: post #49
pjmlp wrote: post #16

It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.

I think the main differentiators for clang were more readable error messages than the mess GCC had (and still has), and faster compilation (here it lost a bit of its advantage over time). I haven't heard of anyone praising it over GCC based on standard compliance. That said, when I explore weird edge cases in how differently Clang and GCC parse source code, and how differently they optimise it, in my experience Clang…

You don’t have to rewrite anything. C++ keeps backward compatibility. You don’t have to make it sound like it’s the case, and you don’t have to shame the "modern c++ crowd" over that false claim. That’s just uncalled for, unconstructive and partisan discourse. I expect better from HN.

Re: C++20, How Hard Could It Be

#138

Post by kllrnohj »

JonChesterfield wrote: post #74

Way too many of those points are "this sane looking code no longer works, fix by rewriting it to be significantly longer"

Eh? There's the NVI comparison operator that fits that bill and maybe the std::forward_iterator one but the rest? Most of the other fixes was less code that's also simpler. Or are you getting thrown off by things like the enum slides where it's 3 different solutions all presented on a single slide?

Re: C++20, How Hard Could It Be

#139

Post by leni536 »

pjmlp wrote: post #123
leni536 wrote: post #76

Earlier quoted context omitted.

umm, you can edit: to elaborate both g++ and clang++ implement the Itanium C++ ABI[1]. You might get binary incompatibility by mixing standard libraries, so just don't do that. [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Which is exactly what happens when using shared objects. Additionally the C++ ABI doesn't tell anything about how each binary library was compiled regarding compiler and linker switches that affect runtime behaviour.

> Which is exactly what happens when using shared objects.

Right. This has nothing to do to gcc, clang and even C++ though. I would be surprised if you could freely link C shared objects linked to different libc implementations.

On most Linux distros both gcc and clang link to libstdc++, so everything works out of the box. I imagine this is not the case for MacOS xcode and gcc from homebrew.

Re: C++20, How Hard Could It Be

#140

Post by hi_herbert »

ghosty141 wrote: post #104
hi_herbert wrote: post #54

Earlier quoted context omitted.

What is the status of ubsan, msan, tsan and others support for GCC though? Last time I checked they were a bit behind. I agree GCC make clang obscolete regarding C++ support and even performance. I don't know a comprehensive alternative to clang linter but I'm sure there are a few. Given that llvm receive more human resources than gcc by far, I once expected it to outperform gcc generally (e.g support for polyhedral…

At work GCC is a lot slower than clang, the project uses a bit much template magic but still, clang is faster. Where does this GCC is faster thing come from? I personally havent experienced it

I mean faster runtime performance, I have no clue about compilation time. Well I'm basing this on the countless benchmarks I've seen, e.g. on phoronix over the decade. Also you have to understand that Clang -O2 is (was) "unfair" as GCC did not enable autovectorization until -O3. This has (is being?) changed.
Post reply on HN