oversearch
commented
11 months ago I personally don't mind a boost dependency on the project. It has a lot of great stuff that you wouldn't want to re-implement yourself, and a large number of C++ projects are already using it anyway. That header list you posted has some nontrivial stuff that won't be in the STL anytime soon or ever.
That said, I will note that ASIO is updated a bit more frequently, and with more serious changes than most Boost libraries. This makes the independent ASIO library more attractive.
At my company, we use Pulsar from two separate C++ code bases, one of which is unfortunately tied down to an old boost version (we're trying to fix that, but it's a huge code base). In order to get Pulsar to build under this and get consistent behavior/performance, I started maintaining a custom fork of Pulsar with boost::asio renamed to just asio::, and we utilize the independent ASIO library in both. It works very well and the changes were pretty simple (you need to fix the "error code" type as well) - a days worth of work.
One thing you could consider doing is just using a preprocessor definition to allow the ASIO namespace to be customized, so users could choose which library they wanted (heavy boost users on a greenfield version will no doubt find that convenient). Just my two cents as a heavy commercial Pulsar user.
BewareMyPower
merlimat
The Boost headers are huge, taken 1.83 for example:
However, the core component we actually need is Boost.Asio or Asio:
Here is the header list that include a header from Boost: