Use character-by-character comparison for comparison operators #112
Conversation
This follows the proposal in section [uri.header-synopsis.equality-comparison]. Otherwise the type would do expensive allocation due to normalization of the URIs when used in containers or algorithms. The operator functions have been made friend functions of the uri class to take advantage of comparing the underlying string_view instead of re-implementing the behavior based on iterators.
There was a problem hiding this comment.
Thanks for identifying this problem and creating a PR.
If I understand what you're trying to do (make the equality operator more efficient by comparing the underlying string_view), I would think it might be much simpler to create an accessor for the view:
string_view uri::string_view() const noexcept {
return view_;
}
(cf. also string(), wstring(), ustring16() etc. member functions)
Then you can implement the equality and comparison operators in terms of this and you don't need to make the operators friends.
Otherwise I agree with comparing the views directly and not calling the compare function.
Did you try to measure the performance?
test/uri_comparison_test.cpp
Outdated
| @@ -70,7 +70,7 @@ TEST(uri_comparison_test, inequality_test) { | |||
| TEST(uri_comparison_test, less_than_test) { | |||
| // lhs is lexicographically less than rhs | |||
| network::uri lhs("http://www.example.com/"); | |||
| network::uri rhs("http://www.example.org/"); | |||
| network::uri rhs("http://www.example.com/path"); | |||
There was a problem hiding this comment.
Was there an issue with the original test? I'd prefer if you added this as a new test case instead of modifying an existing one.
There was a problem hiding this comment.
Yeah sure I should have added that case instead of replacing the existing one.
I did a mistake when re-implementing operator< before deciding to use the string_views operators. I think now that this is using string_view::operator< there is no need to increase test coverage here.
There was a problem hiding this comment.
Reverted in 1a55ecf
|
Thank you for the review! Introducing a I still went with your solution in c0de1e3 and called the accessor |
|
I didn't rebase, so now |
|
I noticed that after I merged them... I can only do that later. Thanks again for the PR. What are you using the library for? |
|
I just used it to represent URIs in our code base for referencing resources. Given it was based on the standard proposal and already ran through some review it made sense to not re-invent the wheel. Regarding your benchmark question: I didn't write benchmarks but previously the compare function normalized both URIs which allocates memory and re-parser the whole thing, so this is probably magnitudes faster now. |
This follows the standard proposal in section [uri.header-synopsis.equality-comparison].
Otherwise the type would do expensive allocation due to normalization of the
URIs when used in containers or algorithms.
The operator functions have been made friend functions of the uri class
to take advantage of comparing the underlying string_view instead of
re-implementing the behavior based on iterators.
I adapted the less-than operator test to use a more interesting example as I did a mistake initially.
@glynos I'm not sure you want these kinds of API breaking changes. I still thought I create a PR to discuss.