CODEWITHSUNDEEP
c++c++17string-view
golden retriever
golden retriever

Reputation: 347

c++17 Ambiguity when compare string_view with string

I saw both std::string_view and std::string have symmetric operator==() and for std::string it has the constructor to accept std::string_view and operator to convert itself to std::string_view. So when we try to use operator==() compare between std::string_view and std::string, is it supposed to be ambiguous?

I think there must be something wrong with my thoughts. Can anyone clarify?

Example:

std::string s1 = "123";
std::string_view s2 = "123";
// in the following comparison, will s1 use the convert operator to generate a string_view, or will s2 use string's string_view constructor to generate a string?
if (s1 == s2) {...}

Upvotes: 17

Views: 17845

Answers (2)

Piotr Skotnicki
Piotr Skotnicki

Reputation: 48487

The reason such a comparison cannot be ambiguous is that neither std::string nor std::string_view are plain types. Instead, these are class templates instantiations, and so are respective comparison operators:

template <class charT, class traits, class alloc>
constexpr bool operator==(const basic_string<charT, traits, alloc>& lhs,
                          const basic_string<charT, traits, alloc>& rhs) noexcept;

template <class charT, class traits>
constexpr bool operator==(basic_string_view<charT, traits> lhs,
                          basic_string_view<charT, traits> rhs) noexcept;

Such defined function templates do not consider any conversions. Instead, they expect the operands to be of exactly the same type, as only then the deduction succeeds (the same types can be deduced for template parameters of left and right operands), producing a viable candidate. Similarly:

template <typename T>
void foo(T, T);

foo(42, 'x'); // error

fails due to mismatch of types of arguments, as T cannot be either int or char, although conversions between the two exist. Also:

struct my_string
{
    operator std::string() const { return ""; }
};

std::string s;
my_string ms;
s == ms; // error

fails, because the compiler cannot deduce basic_string<charT, traits, alloc> from my_string, although there does exists an implicit conversion to its instantiation.

The comparison s1 == s2 does, however, work, because the implementation of the standard library is expected to provide overloads that can consider implicit conversions from any type to std::basic_string_view (such an implicit conversion exists from std::string to std::string_view). This can be achieved, e.g., by inhibiting deduction for one of the parameters, as shown in the example part of [string.view.comparison]/p1:

template <class charT, class traits>
constexpr bool operator==(basic_string_view<charT, traits> lhs,
                          __identity<basic_string_view<charT, traits>> rhs) noexcept;

By putting the type of one of the operands in __identity defined as template <class T> using __identity = decay_t<T>;, it introduces a non-deduced context, creating an overload for some std::basic_string_view and another argument implicitly convertible to the same instantiation of the std::basic_string_view class template.

Upvotes: 19

Nicol Bolas
Nicol Bolas

Reputation: 473926

This works because of an odd clause in [string.view.comparisons]:

Let S be basic_­string_­view<charT, traits>, and sv be an instance of S. Implementations shall provide sufficient additional overloads marked constexpr and noexcept so that an object t with an implicit conversion to S can be compared according to Table 62.

And Table 62 lists all of the comparison operators, with the view on either side of the expression.

Since std::string has an implicit conversion to std::string_view, it is this overload which will be chosen. Such overloads will have an exact match to the s1 == s2 case, so implicit conversions will not be considered.

Basically, this is implemented through SFINAE tools. Something like this:

template<typename Str>
std::enable_if_t<std::is_convertible_v<std::string_view, Str>, bool> operator==(const Str &rhs, const std::string_view &lhs);

Such an overload doesn't require implicit conversions, so it's better than any overload that does.

Upvotes: 6

Related Questions