mercredi 3 août 2016

Why can't std::is_permutation act between two different types of data?

Suppose I have a vector of integers and of strings, and I want to compare whether they have equivalent elements, without consideration of order. Ultimately, I'm asking if the integer vector is a permutation of the string vector (or vice versa). I'd like to be able to just call is_permutation, specify a binary predicate that allows me to compare the two, and move on with my life. eg:

bool checkIntStringComparison( const std::vector<int>& intVec,
                 const std::vector<std::string>& stringVec,
                 const std::map<int, std::string>& intStringMap){
  return std::is_permutation<std::vector<int>::const_iterator, std::vector<std::string>::const_iterator>(
        intVec.cbegin(), intVec.cend(), stringVec.cbegin(), [&intStringMap](const int& i, const std::string& string){
    return string == intStringMap.at(i);
  });
}

But trying to compile this (in gcc) returns an error message that boils down to:

no match for call to stuff::< lambda(const int&, const string& >)(const std::_cxx11::basic_string&, const int&)

see how it switches the calling signature from the lambda's? If I switch them around, the signature switches itself the other way.

Digging around about this error, it seems that the standard specifies for std::is_permutation that ForwardIterator1 and 2 must be the same type. So I understand the compiler error in that regard. But why should it be this way? If I provide a binary predicate that allows me to compare the two (or if we had previously defined some equality operator between the two?), isn't the real core of the algorithm just searching through container 1 to make sure all its elements are in container 2 uniquely?

Aucun commentaire:

Enregistrer un commentaire