Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Domen Vrankar (domen.vrankar_at_[hidden])
Date: 2018-10-23 22:27:56

V V tor., 23. okt. 2018 ob 10:44 je oseba Niall Douglas via Boost <
boost_at_[hidden]> napisala:

> > I agree with RR, though, these things
> > should not be part of C++, I don't even think the Network TS should be in
> > the standard, it's highly specialized stuff, with heaps of pitfalls [most
> > user posted problems on this list pertain to ASIO [and Beast (no
> criticism
> > intended, it's just complicated stuff)].
>

For the past 8 years I'm using ASIO (and now Beast on top of it) to crate
GUIs as I already know web development and certainly don't feel like
bothering with either platform specific GUI stuff or heavy weight
frameworks such as Qt, WxWidgets,... Especially because web has HTML5 with
all the JavaScript libraries for manipulating graphics already in place.

So from my point of view Networking TS covers a big chunk of my inter
process communication and GUI implementation (in both cases localhost and
remote) letting me ignore Apache/NginX, PHP, C# with its ASP.NET
framework... You might argue that C++ is not the best tool for web dev (and
I would disagree because I really hate the devops and dependency bloat that
the alternatives bring to the table) but if you ignore the "which language
to use" part you can see that web and GUI world is not a small portion of
programming tasks and Networking TS covers it quite well for me as the
basic layer.

For me being a base layer for two very different things (networking and
GUI) is something that most definitely belongs into the standard -
especially since C++ standard is heavily lacking in those two departments.

> I think there is widespread agreement that if we had a decent and
> universal package management solution, most of the standard library
> proposals before the committee would no longer be necessary.
>

Universal minus at least one... Since I had to fight the NuGet packaging
manager in C# today (and have fought the Java maven dependency hell quite
often in the past - different libraries requiring different versions of the
same library that don't play nice with one another) I somehow still believe
that package management solutions are still not developed enough to be
really useful on the language level (rpm and deb repositories not included
[meaning that they are useful] as those start to eat away your nerves only
if you are using an old/under-packaged Linux distribution or really need a
custom build of a latest-latest library version) - so I'm for OS level
package management (other people invest time to make the libraries play
nicely together by using the same versions of one library on which other
depend all the way) and don't see a universal C++ package management
solution as being the thing that solves allot of library problems.

Interestingly, P1031 Low level file i/o and the Networking TS are not
> examples of those. Both require changes to the core language to work
> well. So I think for those two at least, they'd be before the committee
> no matter what.
>

+1

Now regarding the future and present of Boost I'm not a
contributor/maintainer but am a long time user and before C++11 Boost
libraries helped me allot. Unfortunately after C++11 release Boost started
to annoy me as my compilers supported more and more of the standard
implementations while Boost libraries kept their dependencies on boost
versions of those same library parts. This becomes an annoyance and for me
puts Boost not side by side with C++ STD library - instead it puts Boost
more towards the Qt basket where you get the feeling that they want to be
the be all end all framework that tries not to care about STD library as
much as humanly possible (I could be wrong regarding both library
bundles/frameworks but that's the feeling I got).

As an outsider that probably even doesn't have enough C++ experience to
contribute to Boost I see usefulness of Boost libraries such as Asio,
Beast, DLL, Spirit/X3 that are not (yet) part of the standard but solve my
problems - but on the other hand I dislike that DLL requires
boost::filesystem (had some additional issues building Boost because of
that dependency and also had to convert to std::filesystem to
boost::filesystem in the code) and even submitted a patch for Beast so that
I don't need to bother with boost::string_veiw and may instead use
std::string_view.
So from one perspective I like Boost as a location where I know I'll find
quality libraries that will solve my problems but from the other that's the
most that I see in current Boost as I don't have a problem using fmt [1]
<https://github.com/fmtlib/fmt> library that is not in Boost (but I'm glad
that it's trying to get standardized - at least in part).

So to sum up: For me as a Boost library user Boost is a library hub that no
longer works with C++ STD library but instead tries to compete against it
as a Boost-STD library - so just another competitive framework. From my
point of view Boost would become once again a C++ STD addition if it would
contain libraries that are missing from the (latest?) standard and would
use C++ STD parts wherever possible - C++ STD for long term stability,
Boost for innovation and complementing the standard instead of trying to
support N previous standards (or by being packaged differently for each C++
standard - only libraries that are missing from that standard and using
boost substitutes only if they are missing in that standard version).

I know that that is an awful lot of work but my guess would be that these
are one of the rare options for Boost to continue to be C++ STD
complementary bunch of libraries that push the standard forward instead of
being just another "I work alone" blob of libraries that are splitting C++
codebases and being better-quality-C++-only-github-2 (nothing wrong with
that but a different direction to pre C++11 Boost).

On the other hand the only way I'd see Boost as a better place for
currently proposed C++ libraries for standardization would be if C++
standard would say something like "C++ compiler is compliant to standard X
only if Boost libraries X, Y, Z... are shipped with it in a working state"
- and until then I prefer libraries migrating slowly from Boost into the
standard.

Just my two (probably useless) cents.

Regards,
Domen

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>