4 ms·

I'll take a shot in the dark and say they probably value their compile times. Every boost library I've ever used has the tendency to pull in the world from a si

I'll take a shot in the dark and say they probably value their compile times. Every boost library I've ever used has the tendency to pull in the world from a single header and take forever to compile.

lhecker 11y ago
ASIO can be used standalone with any C++11 compiler and the compile times are quite good. If I should make a guess then I'd say that the original author of that part of the library either started before ASIO was standalone and/or simply has a hatred for boost (which would be unwarranted), or he/she was simply more experienced with libevent... IMHO it's quite sad that they didn't use ASIO though as it's far more extensive.
- vvanders 11y ago
  That's the thing about reputation though, really easy to burn and really hard to earn back. I've worked on projects where touching a main header incurred a 1 hour compile even with Incredibuild. You can understand how people can get sensitive with compile times in cases like that.
- niekb 11y ago
  And interestingly, Chris Kohlhoff (asio author) is currently working on an executors library / c++ standard proposal. Other question: how would wangle compare to Cap'n Proto (as the post mentions that wangle is an RPC framework, and is zero-copy)
  - dunkelheit 11y ago
    Zero-copy in capnproto docs and in this blog post actually mean different things (the first means that serialized and in-memory representations of capnproto messages are the same and the second means the absence of copying between user space and kernel space when sending a file over the network).
- Matthias247 11y ago
  I haven't used the standalone version, but I have used the boost version for build a cross platform RPC library quite intensively. Unfortunately compile times there were really bad, for about 10kLoC C++ I had a compile time of nearly 1 minute (about 5years ago on a medium speed machine back then). I later also built the same library using Qt and the compile times were below 20 seconds. I think the differences came from the fact that asio is heavily templated, you get all in headers and favors directly instantiated objects instead of pointers. In QT you mostly have pointers (and therefore work with forward declarations to the implementations). Besides that I think asio is a really good library. It gives you LOTS of options how to handle your workload. E.g. much more than libuv, in the sense that you can mix asynchronous and [non-blocking] synchronous IO calls inside your application, do IO calls from different threads, organize work with executors (io_services) and strands, etc. The drawback is that not all of these patters work good, and giving the users this kitchen sink of functionality could lead to worse results than a more focused approach. E.g. it took me a while to realize that calling io_service.run() from multiple threads is not the best idea.
kinofcain 11y ago
They actually are pulling in boost. System thread and filesystem but not asio, according to the cmake file. The other commenters are probably right that they wanted to integrate with folly's existing async infrastructure.

lhecker 11y ago

ASIO can be used standalone with any C++11 compiler and the compile times are quite good. If I should make a guess then I'd say that the original author of that part of the library either started before ASIO was standalone and/or simply has a hatred for boost (which would be unwarranted), or he/she was simply more experienced with libevent... IMHO it's quite sad that they didn't use ASIO though as it's far more extensive.

vvanders 11y ago
That's the thing about reputation though, really easy to burn and really hard to earn back. I've worked on projects where touching a main header incurred a 1 hour compile even with Incredibuild. You can understand how people can get sensitive with compile times in cases like that.
niekb 11y ago
And interestingly, Chris Kohlhoff (asio author) is currently working on an executors library / c++ standard proposal. Other question: how would wangle compare to Cap'n Proto (as the post mentions that wangle is an RPC framework, and is zero-copy)
- dunkelheit 11y ago
  Zero-copy in capnproto docs and in this blog post actually mean different things (the first means that serialized and in-memory representations of capnproto messages are the same and the second means the absence of copying between user space and kernel space when sending a file over the network).
Matthias247 11y ago
I haven't used the standalone version, but I have used the boost version for build a cross platform RPC library quite intensively. Unfortunately compile times there were really bad, for about 10kLoC C++ I had a compile time of nearly 1 minute (about 5years ago on a medium speed machine back then). I later also built the same library using Qt and the compile times were below 20 seconds. I think the differences came from the fact that asio is heavily templated, you get all in headers and favors directly instantiated objects instead of pointers. In QT you mostly have pointers (and therefore work with forward declarations to the implementations). Besides that I think asio is a really good library. It gives you LOTS of options how to handle your workload. E.g. much more than libuv, in the sense that you can mix asynchronous and [non-blocking] synchronous IO calls inside your application, do IO calls from different threads, organize work with executors (io_services) and strands, etc. The drawback is that not all of these patters work good, and giving the users this kitchen sink of functionality could lead to worse results than a more focused approach. E.g. it took me a while to realize that calling io_service.run() from multiple threads is not the best idea.

kinofcain 11y ago

They actually are pulling in boost. System thread and filesystem but not asio, according to the cmake file. The other commenters are probably right that they wanted to integrate with folly's existing async infrastructure.