Re: URL library?

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-01-22 04:15:32

On Tue, Jan 21, 2020 at 7:37 PM Gavin Lambert via Boost
<boost_at_[hidden]> wrote:
> Though some docs would be nice. ;)

Heh... working on that. And per the Ramey Rule, the doc work has
surfaced defects in the API which I am fixing.  This page has the most
work:

<http://vinniefalco.github.io/doc/url/url/ref/boost__url__basic_value.html>

Still being worked on of course.

> Repeated reinventing of static allocators gives me some pause.  Maybe
> that should be broken out into a separate library first?

Well this is not such an easy thing. One of the goals for all my
libraries is that they can work outside of boost (just define
BOOST_URL_STANDALONE). I could break out this little allocator into
another library, but I doubt it is enough to justify a whole entire
lib. Is there another already existing allocator that does the same
thing? I'm not sure there is.

But even so, users who just need to parse, modify, and compose URLs in
their server, and wish to avoid memory allocations will be glad that
they have a 170-line solution in a single header available to them
without the need to look elsewhere.

> And maybe recently-accepted FixedString could use it too (or you could use theirs)?

FixedString doesn't use any allocator. The reason I use the Allocator
model here (versus my home-brewed "storage_ptr" in Boost.JSON) is
because I want to return std::basic_string from the relevant
functions.

> Glancing at
> https://github.com/vinniefalco/url/blob/develop/include/boost/url/impl/basic_value.ipp,
> it looks like there's quite a bit of duplicate code (eg. between
> set_password and set_encoded_password).
>
> I assume this is related to the desire to avoid allocation, but perhaps
> you could make use of your own static_pool when delegating common
> subtasks, rather than duplicating the logic?

I think what you're proposing is that set_password() can first
percent-encode the string using a local pool, and then pass that to
set_encoded_password(). This will certainly eliminate the duplicated
code. But then we are either placing a limit on the size of the string
that may be passed, or we have the possibility of going to the heap
one extra time (to handle the case where the resulting string is
larger than the static_pool's capacity).

I think I would just rather live with the duplicated code. Although,
if you look closely it isn't _really_ duplicated, there are subtle
variations in it which admittedly are rather resistant to refactoring
although I haven't tried very hard. Open to ideas how it can be
reduced, without the need to allocate.

> (Side note: I find the "wrap at <40 columns" style harder to read.  Who
> has screens that narrow these days?)

No idea
what
you're
going on
about
here.

Thanks