On Tue, Jan 21, 2020 at 7:37 PM Gavin Lambert via Boost
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..., 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