i have been studying ASIO for a while and it has a pretty steep learning curve, you should understand networking in general (especially Berkeley sockets) you need to understand design patterns like reactor and proactor model, you should understand coroutines (the boost ones) and many other design patterns already exist (CRTP and how enable_shared_from_this works) in networking and there is not a single good book or documentation about it (there are but most of them are too vague or too deep for starters without organizing principles, there is also a cpp conference talk about it which i did not understand when i wathced first but after a ~month i got it), you have to collect information little by little from different sources depending of your current understanding, i think ASIO is fantastic but not beginner/intermediate friendly at all so if you are new to networking and want to start with ASIO ... ooh boy good luck
Asio is not a trivial socket library. It offers more than just tcp\udp socket interface, it offers a concept of building multithreaded application with I\O routines. I'm not into details but it seems like it has too many aspects to standardize, and commitee is just not ready to bring it all into standart.
@@sheeftz they're not ready since way too long. Each time, the author applies all interfaces remarks, and each time, the commitee finds another reason not to integrate it
where is a replacement for deprecated codecvt elements? where are the modules? when other languages become easier by implementing high level abstraction for a lot of things, like http, json, etc.. Evolution of standard c++ library rots in a minor low level features. I get that this is also needed, 100%, but we are not living in 2010 anymore, everything gets streamlined, easier to use, to give a developer the tools for faster development. but c++ stays behind in that sense, what that committee is even doing? Thank God there are 3rd party tools that help c++ to stay relevant!
If you are looking for a general purpose tcp\udp network library, asio is a standart de facto. It already supports c++20 coroutines. Not sure if there any other library supports or ever will support native c++ coroutines.
Having watched the standardization effort for many years now, it frankly seems likely that this will never be in the standard. However, I've also used ASIO server-side for about 10 years, and the improvements and advancements in the library during that time period have been astounding. At this point, I'm wondering if it'd even benefit from being in the standard, or if that would instead provide something that'd be standardized, but, due to the relatively static nature of being standardized, unused in practice as compared to ASIO itself.
Probably a good idea to get low-level I/O into the library first. This includes * Files * Pipes * Sockets * FIFO:s * Read/write syscalls * Memory mapped I/O *...
I've used ACE once or twice. It seems well designed but if one claims ASIO is difficult to move around, they should try ACE and then apologize ;) Partly because it is (or at least it seems) huge.
I really like the Pistache API but I got bitten by not realizing it was Linux only. After spending several hours trying to port to FreeBSD with libepoll-shim I gave up and learned to use Beast for my simple service. :P
but what about msys2 package manager? It's a windows pacman port, it has lots of mingw and packages and it's even possible to use some aur packages. And on linux side you have the real arch pacman, so it is kinda cross platform
I don't know why worry about a feature being defined in a standard... Filesystem tools are in c++17 already and still not all is available. Modules were put in c++20, but they are still unavailable. Same with many other features.
I know, I know, I don’t wanna be this guy, but: if you’re client-side, just use libcurl. Yes, it’s C, but it’s SO easy to use and it’s bullet-proof. You can even add -libcurl to the command line util to have it spit out the C code you need to make that request. libcurl is king for a reason. There’s very little need for a C++ lib when libcurl exists.
The C++ tech they're discussing would integrate with polymorphic executors, so you could easily control the scheduling algorithm (parallex vs TBB for instance) and the low-level mechanisms (iouring vs epoll for instance) using senders and recievers for networking.
@@Cons-Cat The video is about networking libraries (libuv doesn’t do what you are talking about, and neither do the libcurl wrappers). What I’m saying is that if you just need to make networking requests, you shouldn’t do any of that stuff you mentioned: you should just use libcurl. Unless you have VERY specific requirements, it’s just easier and better. The fact that you can use C libraries without any friction is one of the superpowers of C++, and it’s sometimes just the right answer.
I heartily disagree that it's easy to use and bullet proof. One quick look at the 'curl_easy_setopt' documentation shows it takes an enum of like over 300 settings which is then followed by a variadic parameter of type 'long, function pointer, object pointer or curl_off_t'. Because it is variadic the compiler will give you no assistance if you pass in something wrong. Libcurl is very powerful, and is great as a base level for something to be built on top of, but it is an absolute minefield for people who don't use it every day and I'd absolutely recommend using something higher level unless you have an extremely good reason to use libcurl. Even just one of the cpp curl wrappers will save you from a huge amount of trouble.
@@cppweekly Indeed it is, and it's a VERY cool feature of curl. It's perfect for when you're developing, you can test it with curl at the command line, then see exactly what code is needed to reproduce the behaviour.
Yes. I am optimistic it will merge the papers for explicit coroutine management, size feedback operator new, pattern matching with is/as, value based reflection, and contracts.
Google abandoning the C++ field and copying Microsoft’s proprietary language strategy isn’t a great look. That they went the route of trying to take out C++, like Microsoft tried with C#, rather than push their other proprietary language, Go, is instructive.
@@headlibrarian1996 Which of Google's programming languages are in any sense proprietary? Fidl? Schism? Go? Dart? Also, to say they're abandoning the C++ field while it is still the basis for basically all of their ongoing computer graphics work and Zircon, and Highway, Abseil, Orochi, seems premature.
i have been studying ASIO for a while and it has a pretty steep learning curve, you should understand networking in general (especially Berkeley sockets) you need to understand design patterns like reactor and proactor model, you should understand coroutines (the boost ones) and many other design patterns already exist (CRTP and how enable_shared_from_this works) in networking and there is not a single good book or documentation about it (there are but most of them are too vague or too deep for starters without organizing principles, there is also a cpp conference talk about it which i did not understand when i wathced first but after a ~month i got it), you have to collect information little by little from different sources depending of your current understanding, i think ASIO is fantastic but not beginner/intermediate friendly at all
so if you are new to networking and want to start with ASIO ... ooh boy good luck
I've built a personal higher level library over asio. Yeah, it was a project to learn but I am very happy with the (very high performance) result.
Sounds to me like you did not check the code examples provided by asio
It depends on what your goals are. javidx9 did a good series on his channel using ASIO which was helpful to me when starting out with ASIO.
@@mat2739 or maybe there’s much more to it than those examples… so much so that you may not even know that you don’t know it
Agree, its one of the harder C++ libraries to learn that I have worked with.
It's unfortunate that the networking library is not supported in c++23.
The 3rd edition of A Tour of C++ which covers 20 and some 23 features is now available and you could update your link to that in the description
Good idea, I'll make a note to do that.
Networking Library still not in C++23? The aim was C++17 😫
The author of Asio must feel pretty tired of all this.
Asio is not a trivial socket library. It offers more than just tcp\udp socket interface, it offers a concept of building multithreaded application with I\O routines. I'm not into details but it seems like it has too many aspects to standardize, and commitee is just not ready to bring it all into standart.
@@sheeftz they're not ready since way too long. Each time, the author applies all interfaces remarks, and each time, the commitee finds another reason not to integrate it
where is a replacement for deprecated codecvt elements? where are the modules? when other languages become easier by implementing high level abstraction for a lot of things, like http, json, etc.. Evolution of standard c++ library rots in a minor low level features. I get that this is also needed, 100%, but we are not living in 2010 anymore, everything gets streamlined, easier to use, to give a developer the tools for faster development. but c++ stays behind in that sense, what that committee is even doing? Thank God there are 3rd party tools that help c++ to stay relevant!
If you are looking for a general purpose tcp\udp network library, asio is a standart de facto. It already supports c++20 coroutines. Not sure if there any other library supports or ever will support native c++ coroutines.
> or ever will support native C++ coroutines
This is quite the bold claim!
Having watched the standardization effort for many years now, it frankly seems likely that this will never be in the standard. However, I've also used ASIO server-side for about 10 years, and the improvements and advancements in the library during that time period have been astounding. At this point, I'm wondering if it'd even benefit from being in the standard, or if that would instead provide something that'd be standardized, but, due to the relatively static nature of being standardized, unused in practice as compared to ASIO itself.
I do think a moving target like network should not be standardized, except maybe a basic simple interface for lightweight work.
Probably a good idea to get low-level I/O into the library first. This includes
* Files
* Pipes
* Sockets
* FIFO:s
* Read/write syscalls
* Memory mapped I/O
*...
That's precisely what prevented it from reaching C++23. The current leading proposal is named llfio.
For dude who made subtitles:
QT - QuickTime
Qt - that "Cute" framework
P.S. Thanks, great video, Jason!
Crow should have been mentioned here.
I can't recommend ZeroMQ enough. Really flexible and fast. Easy to set up complex architectures.
I've used ACE once or twice. It seems well designed but if one claims ASIO is difficult to move around, they should try ACE and then apologize ;) Partly because it is (or at least it seems) huge.
Pity that C++ lacks in the standard library. For making a basic application one needs to use all kinds of 3th party libraries.
I really like the Pistache API but I got bitten by not realizing it was Linux only. After spending several hours trying to port to FreeBSD with libepoll-shim I gave up and learned to use Beast for my simple service. :P
Oh no, I missed that too!
Also do note that libcpr only seems to cover HTTP part of libcurl. Libcurl is very vast and has support for many other application layer protocols.
Ima download it thanks for sharing!!
What's the holdup anyway? It seemed like it was on the fast track for a while and now it just keeps getting delayed?
It's waiting for executors now
What about userver?
but what about msys2 package manager? It's a windows pacman port, it has lots of mingw and packages and it's even possible to use some aur packages. And on linux side you have the real arch pacman, so it is kinda cross platform
Sad..but ASIO and Beast rock...And ZeroMQ is dope...
What of this would you recommend for games?
How about no OS in C++? 🙂
There's more to sockets at least than OS. The llfio proposal intends to support freestanding as well.
I had problems with pretty much every package manager when calling them from CMake. What is the most recommended one?
Try conda
@@versatran01 will do, thanks!
vcpkg
I use the cmake-conan integration, personally github.com/conan-io/cmake-conan
Kissnet is small and slick + it's C++17
I don't know why worry about a feature being defined in a standard... Filesystem tools are in c++17 already and still not all is available. Modules were put in c++20, but they are still unavailable. Same with many other features.
Strange there is no mention of Wt
Wt?
I know, I know, I don’t wanna be this guy, but: if you’re client-side, just use libcurl. Yes, it’s C, but it’s SO easy to use and it’s bullet-proof. You can even add -libcurl to the command line util to have it spit out the C code you need to make that request.
libcurl is king for a reason. There’s very little need for a C++ lib when libcurl exists.
The C++ tech they're discussing would integrate with polymorphic executors, so you could easily control the scheduling algorithm (parallex vs TBB for instance) and the low-level mechanisms (iouring vs epoll for instance) using senders and recievers for networking.
@@Cons-Cat The video is about networking libraries (libuv doesn’t do what you are talking about, and neither do the libcurl wrappers). What I’m saying is that if you just need to make networking requests, you shouldn’t do any of that stuff you mentioned: you should just use libcurl. Unless you have VERY specific requirements, it’s just easier and better. The fact that you can use C libraries without any friction is one of the superpowers of C++, and it’s sometimes just the right answer.
I heartily disagree that it's easy to use and bullet proof.
One quick look at the 'curl_easy_setopt' documentation shows it takes an enum of like over 300 settings which is then followed by a variadic parameter of type 'long, function pointer, object pointer or curl_off_t'. Because it is variadic the compiler will give you no assistance if you pass in something wrong.
Libcurl is very powerful, and is great as a base level for something to be built on top of, but it is an absolute minefield for people who don't use it every day and I'd absolutely recommend using something higher level unless you have an extremely good reason to use libcurl.
Even just one of the cpp curl wrappers will save you from a huge amount of trouble.
I'll have to check out your --libcurl option, I did not know that was a thing.
@@cppweekly Indeed it is, and it's a VERY cool feature of curl. It's perfect for when you're developing, you can test it with curl at the command line, then see exactly what code is needed to reproduce the behaviour.
Will there even be a C++26?
There are also plans for C++29. So yeah.
Of course.
Yes. I am optimistic it will merge the papers for explicit coroutine management, size feedback operator new, pattern matching with is/as, value based reflection, and contracts.
Google abandoning the C++ field and copying Microsoft’s proprietary language strategy isn’t a great look. That they went the route of trying to take out C++, like Microsoft tried with C#, rather than push their other proprietary language, Go, is instructive.
@@headlibrarian1996 Which of Google's programming languages are in any sense proprietary? Fidl? Schism? Go? Dart?
Also, to say they're abandoning the C++ field while it is still the basis for basically all of their ongoing computer graphics work and Zircon, and Highway, Abseil, Orochi, seems premature.
Switch to Rust or Go
U didn't even say Qt
To go maybe rust not really makes no sense.
@@platin2148 I don't know a lot about Rust's standard library. Does it not have networking abstractions?
@@Cons-Cat i am almost sure it doesn't, you have to use external crates which is. fun when compiling
Switch to another youtube channel if you don't understand that this one is dedicated to C++ 🙄