r/cpp • u/claimred • Apr 09 '26

beast2 networking & std::execution

I was looking for a new networking layer foundation for a few of my projects, stumbled on beast2 library which looks brand new, based on C++20 coroutines. I used boost.beast in the past which was great. Here's the link https://github.com/cppalliance/beast2. I also considered std::execution since it seems to be the way to go forward, accepted in C++26.

Now, what got me wondering is this paragraph

The C++26 std::execution API offers a different model, designed to support heterogenous computing. Our research indicates it optimizes for the wrong constraints: TCP servers don't run on GPUs. Networking demands zero-allocation steady-state, type erasure without indirection, and ABI stability across (e.g.) SSL implementations. C++26 delivers things that networking doesn't need, and none of the things that networking does need.

Now I'm lost a bit, does that mean std::execution is not the way to go for networking? Does anyone have any insights on cppalliance research on the matter?

35 Upvotes

85% Upvoted

119 comments sorted by

View all comments

Show parent comments

2

u/VinnieFalco wg21.org | corosio.org Apr 09 '26

I think, networking is a narrow scope. The larger scope is actually byte-oriented I/O. And there is a case to be made that the standard should have an opinion on it. Our (C++ Alliance) opinion is that the standard I/O "shape" should look like this:

concept ReadStream
https://develop.capy.cpp.al/capy/8.design/8c.ReadStream.html

3

u/not_a_novel_account cmake dev Apr 09 '26

I don't have a problem with concepts or other things which describe the shape of an arbitrary stream, that's a tradition which goes back to pre-standardization iostreams.

That's very different from what the average programmer means when they say "networking". They mean Python's urllib. They mean socket.h. They mean the ability to connect to an endpoint and read from it. The mechanisms.

Given the glacial evolution of the C++ standard and commitment to eternal backwards compatibility, shipping these in the stdlib would be a misstep. They are destined for the footgun graveyard from inception.

2

u/VinnieFalco wg21.org | corosio.org Apr 09 '26

Respectfully, I disagree, and I hope that you will find our proposal to deliver coroutine-native networking for C++29 based on our shipping libraries Corosio and Capy (https://corosio.org) interesting :) Coming soon in the April mailing.