networking-ts-impl VS llfio

Hi, I am an experienced C++ programmers, but a beginner by network programming. I plan to develop a C++ network application, so decided to try the Networking TS. I have been trying to figure out how to use it for 3 days, and I am starting to understand things a little. I first tried using the std::experimental::net that comes with gcc in Ubuntu 20.04, but it turned out to be incomplete. In order to make the code work, I had to use this github repository instead: https://github.com/chriskohlhoff/networking-ts-impl. The last commit was 2 years ago. Is it the recommended implementation? I tried to teach myself how to use it by following the boost::asio tutorial. It was a bit difficult because of the differences between the two libraries, but I managed to translate the asio tutorial samples without using any boost library. I was surprised that I had to pass the port number as a string to net::ip::tcp::resolver::resolve. Wouldn't it be much better to use an int override, both in terms of implementation and usage of this function? I really don't like having to convert my port number to a string. Is there a way to do it without the conversion? I also dislike the enable_shared_from_this trick used in the boost::asio examples. It looks like a dirty anti-pattern. I feel it is possible to do things much more cleanly without it. I tried to implement an echo server differently: the server keeps a std::list, and the completion handlers are members of the server class instead of the connection class. They take an iterator to the list as parameter, and can cleanly erase the connection from the list. I feel it is much cleaner and simpler than sending connections from lambda to lambda, and using tricks to let them commit suicide by themselves. Is there any advantage of enable_shared_from_this compared to what I do? The scope of boost::asio is wider than networking, and I am surprised that C++ seems to be restricting it to networking. I understand that standardizing a library is a lot of work, and taking care of networking first should‍ have priority. But why not call it std::asio instead, and leave the possibility to add asynchronous file operation to it later?

The reference library can be found at https://ned14.github.io/llfio/

Thanks for the suggestions, which I have transposed into https://github.com/ned14/llfio/issues/106

There was an effort to get an afio library accepted into boost in the past. I believe the most current work on that library is happening here nowadays : https://github.com/ned14/llfio I'm not sure if it is considered production-ready or not. But I couldn't see any mention of it in the replies so I figured I would fix that!

It has an implementation: LLFIO

I'm a fan of Interprocess, used it for over a decade. But for mmapping I've switched to LLFIO and recommend it highly. (Plugging so Niall doesn't have to.)

Since that post, I have the reference implementation library very nearly passing its test suite https://github.com/ned14/llfio/pull/89. Once it's done I'll start very slowly writing its proposal paper for WG21 SG4. Should land before this summer.

FYI it doesn't solve quite what you're solving, but I've been careful to ensure https://github.com/ned14/llfio works well on Freestanding and < 64 Kb microcontrollers and I know Victor has been careful to ensure a good subset of std::format could work well on embedded. In other words, the i/o story for embedded C++ may improve greatly in the next few years.

If you want stronger guarantees than iostreams can give you, either use the OS-specific calls or a wrapper of said calls (e.g. https://github.com/ned14/llfio, disclaimer I'm the owner of that). Note that even in LLFIO, there is no concept of "seek to the end" because that's racy so we don't implement that. All you get is atomic append, otherwise you're on your own to coordinate what "end of file" means.