|
Chandler Carruth
@
chandlerc1024
San Jose, CA
|
|
Software, performance, optimization programming languages, security, open source, LLVM, Clang, C++. pronoun.is/he
|
|
|
2.344
Tweetovi
|
118
Pratim
|
11.001
Osobe koje vas prate
|
| Tweetovi |
|
Chandler Carruth
@chandlerc1024
|
24 h |
|
You could have an independent mechanism for accessing platform libraries. We (almost) have that on Linux with their C APIs & ABIs.
Pinning all of C++ (and its standard library) down with a stable ABI for the entire thing largely blocks evolving any of them for performance.
|
||
|
|
||
| Chandler Carruth proslijedio/la je tweet | ||
|
Titus Winters
@TitusWinters
|
3. velj |
|
What discussion points / lines of reasoning / etc do people find most compelling in discussions about C++ ABI compatibility? (Context: prepping slides for the discussion of wg21.link/P2028 and wg21.link/P1863 next week.)
|
||
|
|
||
| Chandler Carruth proslijedio/la je tweet | ||
|
Chris Armstrong ⚛
@DrCDArmstrong
|
3. velj |
|
One thing I've been doing a lot in marking recently is changing the rubric language from:
"poor ➡️ okay ➡️ good ➡️ very good ➡️ excellent"
to something more like:
"emerging➡️ developing➡️ capable➡️ competent➡️ mastered"
I've found it a lot easier to use.
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
The combined beauty and disappointment of std::vector... 🤦
But out of curiosity, what would be the right direction?
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
I have a very complex relationship with sleep.
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
Totally missed the correct meme-response to this one... twitter.com/blelbach/statu… pic.twitter.com/ch7lQoNafZ
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
I'm really trying to not have that rule.
But I'm running out of reasons *to* use `std::*`.
If we prioritize ABI / compat over performance in Prague, 🤷🏻♂️
Is it a blanket rule if we just run out of use cases that actually work?
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
Sure, but then we should stop spending *obnoxious* amounts of money on the standard library.
My users actually want the standard library to cover this kind of stuff. They shouldn't need 90% of what is in Abseil (or other similar libs).
But, as you point out, today they do. =/
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
Not really IMO...
std::filesystem is something of a disaster. Basically unusable for many for example.
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
I'm not really trying to zero in on Boost, sorry if that came across.
I'm saying I don't think *any* library (or even a collection of libraries) addresses enough of what is needed to meaningfully make the process of WG21 LEWG scale up the way it needs to...
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
I don't think the existence of boost made the bandwidth much better.
Boost isn't a panacea to standardization. =/
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
As has come up several times -- there is no need to implement this in a way that *requires* the name to be stored and available when it would be unreasonable to do so...
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
Maybe the wrong thread, but genuinely interested in where these are. Not saying they don't exist, just find them interesting.
I've generally expected there to be choices that are specific to some of our *use cases*, but I feel like we are not (completely) alone w/ those...
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
Good thing its open source and used elsewhere?
github.com/abseil/abseil-…
=D
Anyways, I'm happy to have more libs that provide this.
My point is -- the standard library still seems like it *should* be a better target... but at this rate, it isn't viable.
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
I agree!
But you're still arguing for why this is abstractly good.
That's not the point Bryce made (I think).
He's saying: even if it is abstractly good, it is less important than things *we already don't have time to do*. And *that* is an argument that rings true... =[
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
I have trouble arguing Bryce is wrong here. The committee *is* struggling to keep up.
Put differently, it isn't useful to compare against proposals we *do* entertain.
Instead ask: is this more important than things we *don't* entertain for bandwidth? Not sure that it is. =[
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
;] I think I'm reasonably aware.
I also don't look at it from that perspective. Or even from a single perspective.
My team maintains toolchains ranging from CUDA & GPUs, to servers with 100 - 100k threads, and desktop apps with 1-100...
Users in each bracket would benefit IMO.
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
Yeah, if this were super hard to implement, I'd understand the reluctance.
The fact that we have a plausible space of possible implementation strategies and approaches, but no time/resources to dig into them? Yikes....
|
||
|
|
||
|
Chandler Carruth
@chandlerc1024
|
31. sij |
|
I have Abseil, so I'm good there.
But think about what this means for our ability to actually build and evolve standard libraries: we can't enable names on threads.
Good luck with all the hard stuff!
|
||
|
|
||