ok this is turning into a rant. you might want to skip over this.
ive done the same at github.com/samiam308/coalbotbeta/. i ended up using boost asio + beast, and nlohmanns json. damn thing takes way too long to compile for such a simple and unsafe bot.
there is a standalone version of asio that doesnt use boost, so you could port beast to that, but i wouldnt say wasting your time with any of it is a good idea. asios completion token system is a mess. when you make a call into an io operation, you are instantiating maybe dozens of templates, depending on how many other operations that io operation does. all that gets you is big compile times, big binary sizes, and big instruction cache thrashing. i like being able to change the way the result is returned back to me, but putting it that close to the actual operation is a horrible idea.
plus, absolutely nothing can be written in separate translation units, unless you want to spend hours writing some extra complex wrappers for each operation on top of the boiler plate needed for supporting completion tokens. and while wrapping a completion token is already kinda tricky, wait until you try passing streams around, the io functions take templated buffers so you cant pass them around unless you want to limit yourself to regular const_buffer or mutable_buffer, meaning you will likely have to write new wrappers for each operation and its constraints.
i have no idea how asio made it into c++20 with this problem. we need to separate the completion token code into something polymorphic (good opportunity to fix std::futures too), and make streams polymorphic.
theres no custom event loops either. having a standardized event loop is nice because then multiple libraries can use the same one. but, theres plenty of valid reasons to be using a different event loop. maybe its performance, maybe its because someone already wrote their code around another event loop before the standards came out. in the second case, if the original loop is customizable, maybe they can wrap the original loop around io_context before they can include that library. in the first case, they will have to use threads and maintain two event loops, and that library will not run as fast as they would like.
anyway, about beast http, its also low level. you have to open the connection yourself and make the request, then either close it or manage a list of open sockets. i was never able to get this right, but thats on me, not the developer of beast.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
ok this is turning into a rant. you might want to skip over this.
ive done the same at github.com/samiam308/coalbotbeta/. i ended up using boost asio + beast, and nlohmanns json. damn thing takes way too long to compile for such a simple and unsafe bot.
there is a standalone version of asio that doesnt use boost, so you could port beast to that, but i wouldnt say wasting your time with any of it is a good idea. asios completion token system is a mess. when you make a call into an io operation, you are instantiating maybe dozens of templates, depending on how many other operations that io operation does. all that gets you is big compile times, big binary sizes, and big instruction cache thrashing. i like being able to change the way the result is returned back to me, but putting it that close to the actual operation is a horrible idea.
plus, absolutely nothing can be written in separate translation units, unless you want to spend hours writing some extra complex wrappers for each operation on top of the boiler plate needed for supporting completion tokens. and while wrapping a completion token is already kinda tricky, wait until you try passing streams around, the io functions take templated buffers so you cant pass them around unless you want to limit yourself to regular
const_bufferormutable_buffer, meaning you will likely have to write new wrappers for each operation and its constraints.i have no idea how asio made it into c++20 with this problem. we need to separate the completion token code into something polymorphic (good opportunity to fix
std::futures too), and make streams polymorphic.theres no custom event loops either. having a standardized event loop is nice because then multiple libraries can use the same one. but, theres plenty of valid reasons to be using a different event loop. maybe its performance, maybe its because someone already wrote their code around another event loop before the standards came out. in the second case, if the original loop is customizable, maybe they can wrap the original loop around
io_contextbefore they can include that library. in the first case, they will have to use threads and maintain two event loops, and that library will not run as fast as they would like.anyway, about beast http, its also low level. you have to open the connection yourself and make the request, then either close it or manage a list of open sockets. i was never able to get this right, but thats on me, not the developer of beast.