result_t foo(params_t);
...
auto result = foo(params);
void async_foo(params_t params, invokable<result_t> cont) { cont(foo(params)); };
...
invokable<result_t> auot receiver= [](result_t result) {...};
async_foo(params, receiver);
auto curried_async_foo(params_t params) {
return [params](invokable<result_t> cont) {
async_foo(params, cont);
};}
...
auto op = curried_async_foo(params);
op(receiver);
auto foo_sender(param_t params) {
return [params](invokable<result_t> cont) {
return [params, cont]{
async_foo(params, cont);
};};}
...
auto sender = foo_sender(params);
auto operation = sender(receiver);
operation();
The complexity is of course in the details, and I didn't fully appreciate it until I tried to implement a stripped down version of the model (and I'm sure I'm still missing a lot).
The model does work very well with coroutines and can avoid or defer a lot of the expected memory allocations of async operations.
And it does look like an interesting proposal
My reduction to continuations is, I think, derived form Eric Niebler original presentation where he introduced a prototype of the idea behind sender/receivers.
Is this true in realistic use cases or only in minimal demos? From what I've seen, as soon as your code is complex enough that you need two compilation units, you need some higher level async abstraction, like coroutines.
And as soon as you have coroutines, you need to type-erase both the senders and the scheduler, so you have at least couple of allocations per continuation.
I did manage to co_await senders without additional allocations though (but the code I wrote is write-only so I need to re-understand what I did 6 months ago again).
I recall that I was able to allocate the operation_state as a coroutine-local, and the scheduler is node based, so the operation_state can just be appended to the scheduler queue.
You still do need to allocate the coroutine itself, and I haven't played with coroutine allocators yet.
Even with different formatters I'd much prefer the tbb variant.
I wrote a lot of plain C and a lot of C++ (cumulatively probably close to MLoC) and I can't remember any C code that would compile in such a short time unless it was a library code or some trivial example.
A lot of it is about making metaprogramming a lot easier to write and to read.
No more enable_if kludges since if constexpr (and concepts for specific stuff); and using concepts allows to better communicate intent (e.g.: template<typename I> can become template<std::integral I> if you want the template to be used only with integer types, and so on)
I’d like to see an example of a task that can be done with less verbosity in C++ than say, Python, using only the standard library
++foo; // Increment value of foo by one
foo += 1 # Increment value of foo by one"Hmm, we need a new keyword to express this complicated idea about how geese move, in other languages they seem to use the keyword fly"
A1: Just re-use this existing four letter keyword 'swim'. Yeah, technically a goose can also swim but that's different, and the ideas aren't similar, and the implementation is entirely different, but this way we didn't need a new keyword so it's less work for a compiler right?
A2: Simple, new keyword complicated_goose_motion - why are people not happy with that?
At some point a noob will ask "Hey why can't we just name it `fly` like in Other Language?" and they will be ridiculed because of course several C++ companies have used the word fly as an identifier in software, and so reserving that word would incur a slight annoyance for them, whereas just forcing either A1 or A2 avoids a little work for those companies and is thus better...
The authors and NVIDIA do not guarantee that this code is fit for any purpose whatsoever.
And say that it worries them. This is actually a warranty disclaimer (the warranty of fitness for a particular purpose) and has to be written like this to be effective. So I would not read anything into it
What will it compile to? Check out Compiler explorer [0].
What will it perform like? Use benchmarks [1] [2]. Remember that benchmarks heavily depend on what system you're using. Benchmarks for generically-compiled software on modern hardware will look very different than benchmarks for the same software but hyper-optimized to run on 10-year-old hardware.
So: if it's not tested, it's not Engineered.
For tests, I strongly prefer GTest [3], for a fairly consistent API across benchmarking, testing, and mocking.
> there's a constant influx of new syntax and new concepts in C++
Yes, but you don't have to use all of it. You can still use older C++ if you really want to. I wouldn't recommend it though. I think the "sweet spot" right now is around C++17. It's got quite improved safety compared to "old" C++ (say... pre C++11) and is fairly easily understandable if you're coming from "old" C++.