Re: URL library?

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2020-01-21 10:01:07

On Tue, Jan 21, 2020 at 4:44 AM Vinnie Falco via Boost
<boost_at_[hidden]> wrote:
> Is there any interest in a URL library for Boost?

Yes, interested as well. I typically rely on QUrl (which brings in
QtCore) or WebSocketPP's url,
but I'd prefer a nice one from you and Boost Vinnie.

I had a quick look, and the first thing that jumps to my mind though
is the shear number of files,
in the repo, and even just the source code, for what is a small
library. Do schema and host_type
need their own headers, and sometimes impl/.hpp, .ipp ???

I've known people/orgs with rules like 1-class-1-file, which I find
overly granular.

I've a big fan of "amalgamated" libraries, especially those which are
header-only,
where you can drop just 1 or 2 or 3 files into your project, and build
them as source
with your own code. Lowers the barrier to try something tremendously.

With Boost, the hurdles are high enough, I don't even try before my
org updates the full 3rd party,
every 2 or 3 years...

I'm probably extreme, in doing the opposite of 1-class-1-file, with a
pair of .h/.cpp files that are
more equivalent to an entire library (worse offender is 2K .h, and 14K
.cpp), but it seems
to me that the proposed Boost.URL has an awful lot of source files,
"just" for URL parsing.

I'd have a .h/.hpp/.ipp only myself :).
.h for decls and inlines only with minimum header deps,
.hpp for template stuff with additional includes,
.ipp/.cpp for non-tempate non-inline impls.

but I'm know I'm far from mainstream here :). ---DD

PS: Also saw some references to Boost.Beast in passing.
PPS: Is the allocator support similar to your proposed Boost.JSON?
Could that be an independent component.