Allow using another string_view implementation

[pitrou]

The uri library comes with its own string_view backport. However, I am already using another backport (and of course some people are using C++17 and simply want the stdlib version).

It would be nice to make the uri library configurable in that regard (I'm not sure how though...). Right now I would have to do some invasive patching to get it working for my purposes.

[pitrou]

(note a similar issue may hold for the optional backport)

[glynos]

I don't know what your project requirements are, but if you have access to a C++17 compliant compiler, you can use the WhatWG URL that supersedes this one: https://github.com/cpp-netlib/url

[pitrou]

No, we are C++11-compatible unfortunately :-(

[glynos]

This is going to be difficult to test, as there are going to be many string_view variants, each with tiny differences. Would it be enough to write a simple adapter class around this one, e.g.:

#include <network/uri.hpp>

namespace mynamespace {
class myuri {

  //...

  mystring_view scheme() const noexcept {
    auto sv = url_.scheme();
    return mystring_view(sv.data(), sv.size());
  }

private:
  network::uri uri_;
};
}

[pitrou]

That sounds a bit cumbersome IMHO.

Thinking out loud, one possibility would be to have a parametered design, such as:

// basic_uri.hpp
namespace network {
template <class string_view, template<class> class optional>
class basic_uri {
  // regular class definition here
};
}

// uri.hpp
#include "basic_uri.hpp"
#include "optional.hpp"
#include "string_view.hpp"

namespace network {
typedef basic_uri<string_view, optional> uri;
}

Then in our library I could write e.g.:

#include <network/uri/base_uri.hpp>

typedef base_uri<arrow::util::string_view, arrow::util::optional> uri;

It seems like that would work, though I may be missing something...

[glynos]

Thanks for the suggestion.

First of all, the optional class implemented in this library is not a part of the public interface, so there should be no conflict with interfacing with client code. Secondly, by design, string_view does nothing more than copy a pointer and a integer (to store the size), so there should be almost no run-time cost to using the adapter pattern I recommended above.

Therefore I don't believe there is any benefit to re-defining the uri class to use a parameterized template in this way.

[pitrou]

Right, the adapter pattern wouldn't have a runtime cost, just a per-project maintenance cost. There is also the compilation time cost of having two different string_view implementations + an adapter...