From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-01-21 15:41:57
On Tue, Jan 21, 2020 at 2:03 AM Dominique Devienne via Boost
> 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 ???
Yes, everything is organized that way for specific reasons. Although
the final version of the library may have a slightly different set of
files. For example, I might just get rid of scheme.hpp and everything
> it seems to me that the proposed Boost.URL has an awful
> lot of source files, "just" for URL parsing.
It isn't "just" URL parsing, it is also encoding and decoding
algorithms, custom storage and allocation, and modification of the
> 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.
Boost.JSON has its own special allocator model because of the
hierarchical nature of the JSON container. Since a boost::url::value
is effectively just a string, the allocator model in this new library
is much simpler. A derived class uses the already familiar Allocator
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk