asio
asio copied to clipboard
chriskohlhoff
deprecate standalone
I think we should stop developing standalone. Let the community manage it. If users can't be bothered to install Boost why should we support them? At the same time we can drop C++03 support from the Boost Asio and start moving into the future.
NO! Stand-alone is awesome. I can use cmake's FetchContent and build master from source no fuss. I can't do that with boost. On my Ubuntu 22 machine I'm stuck with version 1.74. So several releases behind.
It would be great if there was standalone beast that used standalone asio :)
I think this is a very bad idea. Also, Boost is required by Asio for C++03 only.
I don't see the obsession with wanting to put stuff in boost anymore. It's no longer used as an incubator for future standard library additions. It wasn't the case for ranges or fmtlib and won't be for senders.
If boost::asio provides the fully standalone possibility of other boost libraries (optional), it might be worth it.
Removing the C++03 compatibility that brings this boost dependency might solve it.
NO! Stand-alone is awesome.
It isn't going away, just no longer developed. And the Boost version would fork, to remove all the standalone support.
I can use cmake's FetchContent and build master from source no fuss. I can't do that with boost.
Well we need to make that work, I think. @pdimov ?
On my Ubuntu 22 machine I'm stuck with version 1.74. So several releases behind.
Well then nothing would change, the issue wouldn't affect you. It only applies to new releases of Boost.
It would be great if there was standalone beast that used standalone asio :)
That's never going to happen for any libraries that I author, for a simple reason. Creating a standalone version means duplicating and maintaining common support infrastructure such as Boost.Config, Boost.Variant2, Boost.MP11, and the rest of all the wonderful Boost libraries which are actively maintained and help me write cleaner and more concise code.
It also sends a bad message, that a Boost is inadequate as offered and has to be provided "standalone." If users can't be bothered to install Boost then why should I hamstring myself?
The development and evolution of standalone libraries is forever stifled by the need to "avoid adding a dependency." This means they are less functional and more poorly improved than their counterparts which have the benefit of the force multiplier that comes from using external libraries.
I dunno. I wouldn't want to be forced to import a mountain of boost just to use latest asio.
Also a library doesn't have to be in boost for it to be great. It's fine where it is IMO
Also a library doesn't have to be in boost for it to be great.
Libraries together in Boost work well and interoperate with each other. Boost.Beast and Boost.Asio. Boost.URL and Boost.Beast. Boost.JSON and everything else. And my new libraries Boost.Http.Proto and Boost.Http.IO which work with Boost.Asio, Boost.URL, and Boost.JSON. Plus theres Boost.MySQL and soon even Boost.Redis both using Boost.Asio.
These don't work at all with standalone Asio, and they never will.
To be honest, if cmake FetchContent worked with boost I wouldn't mind too much provided it didn't generate enormous binaries. All those libraries sound great but I don't see why asio should change for the sake of other libraries. Other libraries should adapt to Asio.
And my new libraries Boost.Http.Proto and Boost.Http.IO which work with Boost.Asio, Boost.URL, and Boost.JSON. Plus theres Boost.MySQL and soon even Boost.Redis both using Boost.Asio.
These don't work at all with standalone Asio, and they never will.
It's not Asio dependent on Boost. It Boost (and your libraries) depends on Asio.
Interesting, I am using Asio with C++17 (maybe filesystem library in C++20 soon) and never bother to use a post libraries. I also use standalone http parser for Http 1.1 and Quiche/ nghttp2 for Http 2 and 3 support. Boost doesn't meat these requirements.
Boost is too large, every excessive dependency is new expense to maintain, developers don't want to deal with that.
As a user of the asio standalone, I was so relieved when I found out I could use it as a standalone. If I incremented a variable every time I've seen READMEs that say "no longer using boost as a dependency! 🎉" I would hit INT_MAX. It was also a great joy when my codebases reached that state as well. I don't think we should be trying to go back.
@vinniefalco
the rest of all the wonderful Boost libraries which are actively maintained
I'm sorry, but... "rest wonderful" or really "rest in peace"?
For example.
Very interesting libraries Boost MultiIndex, Accumulators, Bimap and many other: Depends on the huge and outdated Boost.MPL.
program_options, property_tree, etc...: Many years without fix a bugs and other progress.
etc..., etc.
Maybe update them first? For example, upgrade to C++11, which will significantly reduce the number of dependencies and simplify the code.
P.S. I apologize for the negative connotation of the message.
I apologize for the negative connotation of the message.
I appreciate the feedback. I think we can improve these issues that you pointed out.
Libraries together in Boost work well and interoperate with each other. Boost.Beast and Boost.Asio. Boost.URL and Boost.Beast. Boost.JSON and everything else. And my new libraries Boost.Http.Proto and Boost.Http.IO which work with Boost.Asio, Boost.URL, and Boost.JSON. Plus theres Boost.MySQL and soon even Boost.Redis both using Boost.Asio.
These don't work at all with standalone Asio, and they never will.
"and they never will" - that is unfortunate. I believe the listed libraries might have happily existed under "Beast" label, which could have a standalone version.
If users can't be bothered to install Boost
The reasons why users might not decide to use Boost are not limited to installation issues. And from my experience in the last 5 years integrating Boost in your dev-environment and/or CI is not an issue (we have package managers and dockers, and all that is nicely integrated with IDE).
Here is what I think might be a subject of being bothered.
-
Boost as the whole huge thing has a higher comprehension barrier compared to other libraries that are more focused on a specific task or set of related tasks. To illustrate the point, imagine a user who wants to delve into the library's code, for instance, to patch it or debug issues. Take the library
Boost.Foofor instance, which as part of its implementation for the subtaskXXXuses another libraryBoost.Bar. And here is the thingBoost.Bardoesn't provide a solution toXXXspecifically but instead offers a broader approach for a family of tasks of whichXXXis a member. This means that a user trying to understand and useBoost.Fooneeds to fight a higher level of complexity compared to a possible standalone alternative, where the solution forXXXis provided as is, without generalization. -
Some non-boost libraries are just better (for the user's definition of better in general or for a certain task) than their counterparts in Boost. It's highly debatable but here are some examples that come to mind right away: spdlog over Boost.Log, fmtlib over Boost.Format, simdjson over Boost.JSON (if you only need parsing). And related concern to the above one - there is a process to join Boost but is there a process to get libraries out of it (in case the library is no longer good enough)?
-
And a highly subjective and less of an engineering concern: it feels weird that very technology biassed libraries find their way to boost (MySQL, Redis). Because the Boost I knew was a collection of general-purpose libraries (like an extended std with all goodies that have not made their way to std). Why put technology-based solutions into Boost? To me, MySQL and Redis libs belong to MySQL and Redis projects rather than to Boost. If the libraries are good then they can have a happy life as individual libraries based on Boost. otherwise it looks like they need a vouch.
The above is what I think can contribute to an argument against using Boost in a project.
@ngrodzitski thank you very much for investing the time to provide this feedback! You are right, Boost Libraries is like a roach motel - roaches check in but they don't check out. We need a way to gracefully retire libraries.
Reference:
Well, Boost.MySQL has tremendous value in that it's a permissively licensed MySQL client library, compared to the GPL'd official client library.
I think there are other permissively licensed client implementations but Boost.MySQL has a nice ergonomic API and integrates directly with Asio which is a boon.
These libraries have been mentioned: fmtlib, simdjson, asio (standalone). What is interesting is that these three libraries have no other dependencies. It sounds like, the aversion to Boost is not just that no one wants to have a dependency on Boost. It is that users prefer to only use libraries that have no other dependencies.
If you think about it, this is a pretty significant restriction. It means that every library has to use only the stdlib, and reinvent any general facilities that it might need such as configuration macros for portability across toolchains and environments, polyfills for missing std features in earlier versions of C++, and so on.
It should be obvious that this requirement means that libraries cannot scale, because every author has to duplicate increasing amounts of work. And the C++ ecosystem of libraries will never experience the benefit of network effects that comes from libraries building on top of each other. Am I wrong? It feels like something has to change, or C++ will stagnate.
No one wants dependency hell. You include 1 boost library, you accidentally include 10 others
From reading this thread I see that people who avoid Boost do not want to use package managers, but they want to be package managers. They don't want to bother with the hard part (dependency graph resolution), though, because, well it's very hard (NP hard). So, they instead only allow dependencies without any dependencies of their own. This is a very peculiar behaviour. An external observer might want to ask, why not just use a package manager to deal with dependencies? Those don't have the limitation of only flat dependencies and surely it would be simpler than doing things by hand. Both C++ PMs have a solution to monolithic Boost, although they do it differently.
Another interesting observation is the sentiment towards bloat. So, having one copy of Boost.MPL stored somewhere on your hard drive is a bloat that cannot be accepted. But having 10 unmaintained copies of Boost.Config, Boost.Core, Boost.Align and whatever else is not bloat, because they are not explicit dependencies, they are just hidden somewhere inside other libraries. Out of sight, out of mind.
Btw, they are unmaintained because the project maintainer copied them once and then it never receives bug fixes that the sources receive ppl. There was recently a fix to a bug in Config that affected JSON. Now JSON benefits from the fix, because it did not copy the code it just included a header. That's why we add dependencies in the first place, right? To get functionality without writing it ourselves.
So far in this thread I've seen exactly one problem with monolithic Boost mentioned: not being able to use FetchContent. This is actually not true, but regardless, this is just an attempt to do manual dependency management. Use a proper PM!
No other actual problems (and not hand-wavy phrases) were mentioned.
That's all great but sometimes the library shipped with a PM is bloated. Like I use libavformat from ffmpeg but I disable pretty much everything except for one or 2 modules (e.g mp4 and h264). The resulting libs are tiny and have no dependencies themselves. If I were to use the version of libavformat that Conan provides for example, it would have everything enabled, the library file would be ENORMOUS and I would be linking to literally 100 other dependencies I don't care about. So yeah, PMs aren't always the solution.
Same thing for crypto libraries. The versions shipped by a PM have everything enabled and are huge. Sometimes, all you want is AES256 and you don't care about the rest. So building from source manually and only enabling what you need allows you to really strip down your dependency graph (because some of the modules you don't want may require additional deps) and reduce binary size. Doing things like this is what allows me to go from a 100MB binary to 500kB binary. And I need this because the device the binary is going has basically no storage
But I agree package managers are great. It's nice when using python, you can freely pip-install anything you want in your environment and you don't really care. You're happy. But when using c++ I'm usually solving another problem and having 100s of floating shared library deps is not an option. I don't think package managers are good at avoiding that. From what I can see, the library you're given is pre-compile, sometimes from a forked repo with god knows which options.
Going back to the original question. Honestly I don't mind. However I want to use the version of Asio where @chriskohlhoff is going to carry on landing his killer features. He is a god and I want to use his library not someone else's fork.
@vinniefalco
It is that users prefer to only use libraries that have no other dependencies.
No! No! Dependencies should be benefit, not the size of the executable.
Prior to C++11/14, Boost was excellent. The benefits were very high. After C++11/14 Boost doubles the dependencies, size of executables and time of compilation and CI:
-
std::shared_ptr+boost::shared_ptr(by dependencies) - C++11 variadic templates with small
boost::mp11+boost::mpl -
<type_traits>+boost type_traits. - ...
- etc
Each new C++ standard increases this duplication:
-
std::filesystem+boost::filesystem -
std::optional+boost::optional -
std::any+boost::any -
std::variant+boost::variant+boost::variant2
Package managers do not solve this problem.
@grisumbras
But having 10 unmaintained copies of Boost.Config, Boost.Core, Boost.Align and whatever else is not bloat, because they are not explicit dependencies
In C++11/C++14 era, most of these libraries are implemented in libstdc++, libc++ and Microsoft.STL.
Boost was excellent when С++11/14 wasn't. But now Boost brings duplication, which brings errors (see my previous message).
That's all great but sometimes the library shipped with a PM is bloated. Like I use libavformat from ffmpeg but I disable pretty much everything except for one or 2 modules (e.g mp4 and h264).
I thought "that's wierd, Conan packages always provide the same options as the project itself" and sure enough everything is disableable. So, invalid argument.
In C++11/C++14 era, most of these libraries are implemented in libstdc++, libc++ and Microsoft.STL. Boost was excellent when С++11/14 wasn't. But now Boost brings duplication, which brings errors (see my previous message).
Pretty much no part of Config is provided by any implementation. The whole point of that library is to determine which implementation you are using (the implementation already knows this) and what that implementation actually implements correctly (implementation usually cannot know that).
Core has only a few things that aren't replaced by modern core language or library features, but that's still a few.
Same with Align.
BTW, just because an implementation claims to support C++ version X, doesn't mean the implementation does it fully and correctly. So, yeah, with a theoretical spherical C++ implementation in the vacuum of space there's little need for these helper Boost libs, but when you want to work around implementation bugs, they are indespensible.
BTW, I want to point out the irony of only allowing dependencies that have no further dependencies. So, you can reuse other people's code, but the library authors can't? These severely limits the potential space for C++ libraries.