Twitter | Pretraživanje | |
Eric Niebler
Husband, father, software developer, consultant, speaker, trainer, author, artist, coffee drinker, and former wanderer. he/him
2.730
Tweetovi
105
Pratim
5.496
Osobe koje vas prate
Tweetovi
Eric Niebler 3 h
In that case....
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 3 h
Odgovor korisniku/ci @Jeremy_W_Murphy
Wow, I had no idea such a book existed! Thanks.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 14 h
Range-v3 is hardly perfect. is the code conforming?
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 24 h
Odgovor korisniku/ci @timur_audio
Well done. Starting is the hardest part.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler proslijedio/la je tweet
Corentin 31. sij
A Universal I/O Abstraction for C++ New blog post about executors, asynchronous I/O, io_uring, coroutines and more ! ➡️ ⬅️
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 30. sij
Odgovor korisniku/ci @shantanugadgil @the_mabraham
I'm not picking nits. I'm not criticising anybody for using "journeyman." I'm trying to find a different word because *I'm* trying to do better.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 30. sij
Odgovor korisniku/ci @xolvenz @nagyegrimate
Language is flexible. More than some people, it seems.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
Odgovor korisniku/ci @nagyegrimate
"man" will be gender neutral when every person has a penis.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
Odgovor korisniku/ci @normed_space
Ha! I kind of like 'wright'. It has an old-timey vibe.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
Odgovor korisniku/ci @Commuter76 @corneil @gregcons
Interesting! Now I wonder if "journeyman" has a similar negative connotation in American English that I'm simply not aware of.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
Odgovor korisniku/ci @corneil @gregcons
Makes me thing of hipsters with handlebar mustaches.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
Odgovor korisniku/ci @SeanParent
I think it seems backward to you because you have it backward. :-) Senders are producers that yield values. A receiver is basically a callback or continuation, like the rest of the coroutine after a co_await or co_yield. It receives the value that the sender produced.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
In English, a "journeyman" is someone who has acquired a skill through apprenticeship, is proficient and effective though not exceptional. It is exactly the word I'm looking for, except is it unfortunately gendered. Is there a gender-neutral word I could use instead?
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
Odgovor korisniku/ci @bandzaw @edmundm
The retry algorithm itself is an example of such. We might even make them chain with the pipe operator, as range adaptors do.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 29. sij
Odgovor korisniku/ci @SeanParent
"signaled by destruction" ... of what?
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 28. sij
Odgovor korisniku/ci @SeanParent
I suspect the disconnect is because you are thinking of senders as if they were futures. They're more primitive than that. When you destroy a future, there is a tree of asynchronous outstanding work that needs to be cancelled. When you destroy a sender, there's nothing to cancel.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 28. sij
Odgovor korisniku/ci @SeanParent
Sender/receiver doesn't impose a model for requesting stop or of propagating such a request upstream. (IIUC, that's what you want.) It has a channel that a task can use to notify downstream tasks that it has responded to a request to stop.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 28. sij
Odgovor korisniku/ci @SeanParent
Coroutines *always* require additional overhead. The frame is dynamically allocated and the continuation is type-erased. Sometimes the compiler is smart, and sometimes not so much. 🤪
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 28. sij
Odgovor korisniku/ci @SeanParent
Detached computation is often undesirable because it introduces a nasty nondeterminism. Sometimes it's fine, but the fundamental async basis ops shouldn't force it.
Reply Retweet Označi sa "sviđa mi se"
Eric Niebler 28. sij
Odgovor korisniku/ci @SeanParent
Using destruction to request cancellation forces a hard choice because ~T() is synchronous and cancellation is async and racy. ~T() must either block for cancellation to complete or let the cancelled task run detached. Both have their drawbacks.
Reply Retweet Označi sa "sviđa mi se"