I already know about Facebook’s wangle, but it seems to rely more on it, the documentation is not very complete, and it doesn’t seem to have gained much popularity.
From a functional point of view, the only library that can be compared with netty, which encapsulates the underlying API, can be cross-platform, and provides a concurrent operating environment, is boost::asio. From the perspective of widespread use, C++ does not have a library comparable to netty. After all, Java only has netty. For many C++ projects, you can use C network libraries such as libevent (the libraries of C are basically POSIX API encapsulation, and they are not provided. Concurrent operating environment of netty’s executor or asio’s strand). Simply compare the advantages of asio and netty:netty: reactor mode. Easy to use, simple and easy to use. Defines the basic operation process of a server program. A series of APIs in the process are provided and can be used directly. And this set of procedures can basically cover most of the actual needs. Disadvantages: Not flexible enough, assuming a basic operation process of the server. The basic assumption is: the server processing message logic comes in a pipeline manner, and the thread processing channel messages is fixed and will not change. If you want to use your own thread to concurrently use a certain part of the logic, add executorasio to the pipeline. Advantages: flexibility and no unachievable requirements. With the strand design, you can control the granularity of concurrency at will. After all, it is just a queue on the ioservice. And netty’s executor is a real thread. The design of call chain (netty can also be used for some tasks, but netty is not implemented from a design point of view, but it can be done, not like asio is designed and implemented as a functional point) is very easy to use, some Appropriate functions are simple to implement and aesthetically pleasing. The design of io_serivce can be used in environments that do not have its own running thread, such as clients, or even embedded devices (anyway, the design takes into account, depending on whether you can compile it), this is also the name of the asio library called asynchronous The reason for IO, it is too versatile. Disadvantages: proactor mode, difficult to get started. Without making any assumptions about the server running process, you need to decide a process according to the project needs (for example, whether a connected IO message can be processed by multiple threads, these can be determined by yourself). Unlike netty, which basically comes with a bootstrap, it can directly process the received data (still decoded). No buffer is implemented, only a buffer wrapper, you need to write a readwritebuffer yourself (this is a bit painful). Although you can use free function async_write directly without buffer, you need to handle interleaving write yourself. Using sharedptr to manage memory, the core code part is more mind-blowing. For example, we must carefully consider weakptr and the ownership of sharedptr (of course this is not a problem with asio). In general, the language characteristics of these two libraries are very obvious. Netty, you can think of everything you can use, API, class a bunch of direct use. asio, provides a set of well-designed reusable components, complex functions, you have to put it together. In the past few years, asio has been proposing to enter the standard library, but due to the efficiency of the C++ committee, so far, I don’t know when it can enter std. The latest proposal: As for the wangle you mentioned, I personally think that there is no brain The libraries for translating libraries in other languages are not quite on the table. It’s nothing to simply use, but there is no design rationality.