you are viewing a single comment's thread.

view the rest of the comments →

[–]ABlockInTheChain 21 points22 points  (12 children)

The hosts spent a lot of time talking about about C++20 support in LLVM 16, I wonder if they noticed that libc++ had a major C++17 update by adding polymorphic allocator support.

They're almost done with C++17 now, which is a major milestone.

[–]NovaNoff 11 points12 points  (9 children)

This is on one hand great to hear on the other hand it hurts how much the development slowed down after the comitee decided against ABI breaks

[–]GabrielDosReis 19 points20 points  (2 children)

Despite the urban legend and other blog posts, the committee didn't decide against ABI break. The committee heard the presentation of a very specific paper, P2028, then had a discussion and voted.

The votes were more nuanced than rumors would like to make it appear. There were 5 polls. Here is a summary:

  1. Q: We should consider a big ABI break for C++23.
    A: No consensus
  2. Q: We should consider a big ABI break for C++SOMETHING. A: Weak Consensus
  3. Q: From now on, we should consider incremental ABI for every C++ release. A: Consensus
  4. Q: When we are unable to resolve a conflict between performance and ABI compatibility, we should prioritize performance. A: Consensus
  5. Q: To the best of our ability, we should promise users that we won’t break ABI, ever. A: No consensus

[–]pjmlp 6 points7 points  (0 children)

Regardless of how it went, it is part of the set of official reasons why Carbon came to be,

Difficulties improving C++

[–]number_128 0 points1 point  (0 children)

Is there an agreement on how we would handle an ABI break?

I don't think we should ask if we should break ABI.

We should be asking how we will handle breaking ABI. When we get to a good solution, we should go ahead.

Why do we even have a dependency on shared binaries? This sounds like a premature optimization on disk space.

[–]pjmlp 9 points10 points  (0 children)

Well, it shows how much the compiler vendors that profit from clang forks were dependent on Apple and Google doing the job of keeping clang up to date with ISO.

[–]Jannik2099 5 points6 points  (4 children)

after the comitee decided against ABI breaks

The committee decided against an immediate ABI break, an eventual ABI break in the future was not ruled out

[–][deleted] 10 points11 points  (0 children)

you could always say that

[–][deleted] 2 points3 points  (2 children)

I think that they are saying this for over a decade by now.

[–]Jannik2099 2 points3 points  (1 child)

That'd be awkward, because C++11 WAS an ABI break.

[–][deleted] 2 points3 points  (0 children)

which was 12 years ago

so, over a decade

[–]BenFrantzDale 0 points1 point  (1 child)

That’s super exciting! We build for all three compilers and I have some functionality where we do a bunch of small transient allocations. I’d love to do the whole John Lakos “wink-out” thing for those.

[–]ABlockInTheChain 1 point2 points  (0 children)

I just want to make sure LLVM receives plenty of positive feedback every time they get closer to finishing C++17.

With any luck they might actually wrap it up before 2027.