Hacker News new | past | comments | ask | show | jobs | submit login

Don't forget the upcoming "executors" concept. Good talk w/Eric Niebler on why promise/future is not so great[1] and P0443R14[2]. Seems like it won't make it for C++23, though.

  [1] https://www.youtube.com/watch?v=tF-Nz4aRWAM&t=778s
  [2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r14.html



Good to know. std::async for simple and less intensive cases, for anything serious std::thread might be the way to go, before executors is real that is.


Except you can have thousands of std::async threads, and at best a few dozen std::threads.


That's only if the implementation uses a thread pool, I think only MSVC does it, not libstdc++ or libc++ last time I checked


It does not scale per the youtube talk though, the promises/futures are competing with shared resource, which is a surprise.


> Seems like it won't make it for C++23, though.

Why is that?


I'm assuming you're wondering about process rather than why specifically this piece of work was not prioritised enough to get done (which you'd have to ask the relevant people about)

C++ is a JTC1 standard, which means it needs to use ISO processes, which means it needs to produce a CD (Committee Draft) and then that needs to go through formal international processes in which, in principle, there might be objections from ISO's members (which remember are national standards agencies from around the world, on behalf of the sovereign entities) and then those get addressed and only then, months later, is it published as a standard.

So in practice that means WG21 (the C++ committee) needs to have more or less final text for C++ 23 by July 2022. ie the C++ 23 standard is in effect already decided.


I'm not involved, but it seems like they haven't managed to get it fully baked in time for the cutoff. Some more discussion at: https://old.reddit.com/r/cpp/comments/sshm7n/did_unified_exe...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: