Add functionality to split the query into (key,value) pairs

[georgi-d]

It would be great if it was possible to split the query component into a series of (key,value) pairs.

I would suggest having a query_key_values() method which either returns an input_iterator which has a value type of pair<string_view, string_view> or receives an output_iterator which has a value type of pair<string_view, string_view>.

[glynos]

Sorry for the slow response. It might be interesting, I'll try to implement it.

[glynos]

I tried to put something together:

https://github.com/glynos/uri/tree/query_key_values

See the tests in uri_tests.cpp from line 824 to the end of the file.

[georgi-d]

This looks to match exactly what I had in mind. Thanks.

Looking at the tests I was a bit surprised it is possible to de-reference the begin() iterator when it is equal to the end() iterator. It is not a blocker since the typical loop will not de-reference it.

[glynos]

What test are you referring to? That sounds like a bug (actually I fixed another one like that I noticed yesterday).

[georgi-d]

I am referring to TEST(uri_test, query_iterator_with_empty_query)

https://github.com/glynos/uri/blob/query_key_values/test/uri_test.cpp#L832

EXPECT_EQ(instance.query_begin(), instance.query_end());
auto kvp = *instance.query_begin();  // this should probably assert

[glynos]

That test has a bug in it, but I think it should should be EXPECT_NE instead of EXPECT_EQ.

[georgi-d]

This is an interesting case. I feel the more natural would be to stay as is with EXPECT_EQ. The common use case would be

vector<..> v;
for(auto it = instance.query_begin(); it != instance.query_end(); ++it) {
  v.push_back(*it);
}

And I think in this case it is better to end up with an empty vector than to have an entry with empty key and empty value in it.

It will be very unnatural and the users would have to special case this otherwise.

[glynos]

It's a weird one, and an edge case. According to RFC3986 (https://www.ietf.org/rfc/rfc3986.txt), there is a distinction between a missing query and an empty one, such that the following are not equivalent:

http://example.com/
http://example.com/?

I have never seen anyone rely on this in practice, though. I'll leave it as it is, for now.

[glynos]

Applied in #97 and merged into master.