My review of Boost.URL Before answering the questions presented by the review manager, I thought I’d share a few words about what Boost represents to me and why I take an interest in it. Many moons ago, Boost was pretty much the only way to use the C++ programming language in any kind of useful, cross-platform way. Today, the C++ standard has evolved and grown considerably. Many of the original drivers to use Boost are seemingly “solved” in the language itself. Notwithstanding that some of the design decisions taken by the Committee over the years have resulted in an anaemic half-copy of Boost features being standardised. Because of this (in my view) failure of the committee decision process in the face of reality, I still use many of the fundamental Boost utilities in place of their standard counterparts. Therefore, to my mind, Boost is still a necessary component of any non-trivial program I write in C++. Boost also has a collection of utility libraries, some of which have waned in relevance over time. For example, Boost.Format is now pretty much obsolete in the face of fmtlib (not std::format, which is another example of a half-hearted attempt to standardise a solution). When I program, I do so almost exclusively in C++. I don’t really want the bother of having to reach for other languages or to stay current in their dependency management solutions of the day. What I really want is one massive library that I can pull in which does everything I need, or at least the common things. Common things for me are: - Communications, including HTTP, WebSockets, databases and messages buses. - Console IO - Logging - Graphics & Human Interfaces - Sound For me, anything that takes us a step closer to having one library that shrink-wraps all that into one `find_package` call in CMake is a win. Now I will admit that once upon a time, I believed that all this stuff should be in the standard library. However since then, having worked as a library maintainer myself, I have come to realise that this is an error. Giving compiler maintainers the burden of maintaining humongous libraries will simply discourage innovation in compiler technology and result in incomplete implementations and porting to new computing platforms. Boost’s cross-platform compatibility is unparalleled. Therefore I am strongly of the view that the place for C++ library innovation is Boost, and the place for standardising the language changes that are demonstrated as necessary by Boost innovation lies with the Committee and compiler developers. For me, any new library that increases Boost’s real-world utility, is fully cross platform and reduces my workload when writing application programs is very welcome. For for the review:

Does this library bring real benefit to C++ developers for real world use-case?

Yes. URL parsing can be fluked with regex, split and a few hand-rolled utilities. But why give developers the burden of hand-rolling this boilerplate nonsense? Make simple things simple!

Do you have an application for this library?

Absolutely. I am happy to retrofit Boost.URL into existing code and would certainly use it in all future code.

Does the API match with current best practices?

I have no idea what “best practices” are in API design. The API allows me to interrogate, build and update internet URLs. I may have made different naming choices and if I had written it I would probably have made more use of free functions, but I’m not going to argue about style. Utility is all that matters to me.

Is the documentation helpful and clear?

Much like the Boost.ASIO documentation, it is 100% correct and tersely describes the exact functionality of the API. Use of the documentation requires at least a cursory understanding of the terms in RFC3986. Twenty years ago, it would probably have been reasonable to require users to read this RFC prior to using the library. Today, attention spans are shorter and the internet is a commodity. I would prefer to see a little more narrative and descriptions of real-world uses of some of the methods, along with code examples.

Did you try to use it?

Yes, I retrofitted Boost.URL into a program that I used as the basis of a blog post - a program to demonstrate following redirect responses when connecting a WebSocket. I have also integrated Boost.URL into a new program which connects to an exchange in the past week. Doing so saved probably 200 lines of hand-rolled code.

What problems or surprises did you encounter?

The library lacked a specific facility to extract just the HTTP TARGET field from a URL. After reporting this to the author with a supporting use case and hand-rolled work-arwound, this has now been added.

What is your evaluation of the implementation?

It is clear that a great deal of care has gone into making the implementation robust and efficient.

How much effort did you put into your evaluation? A glance?

A quick reading? In-depth study? I retrofitted Boost.URL into an existing program and wrote a new program that uses the library. I spent some time discussing what I felt were missing features with the author, who has been responsive. My required features subsequently appeared.

Are you knowledgeable about the problem domain?

I’ve been writing internet-facing servers and clients in C++ for a decade. In all that time I have never read RFC3986. I suspect like 99% of developers, I have simply inferred the rules of URL encoding through use. So perhaps a time-served journeyman rather than domain expert. Recommendation: ACCEPT The day I can write a CML that has only one dependency, Boost, will be a happy day. -- Richard Hodges hodges.r@gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212