Question

I’m using QVector to hold pointers to Objects, say FYPE*, in my program.

    class TYPE {
        // ....
    };
    const TYPE *ptrToCst;
    QVector<TYPE*> qtVct;
    // ...
    if (qtVct.contains(ptrToCst)) { // Error!!!
        // ....
    }

The compiler says QVector::contains expects TYPE* instead of const TYPE* as its parameter. A const_cast operation would solve this problem. But it doesn’t make any sense to me, since the contains method should never change what the pointer points to. And the equivalent code using STL vector works as expected.

    std::vector<TYPE*>  stlVct;
    // ...
    if (std::find(stlVct.begin(), stlVct.end(), ptrToCst)) { // Ok
        // ...
    }

What’s the reason for this difference? Did STL treat containers that hold pointers specially, so that std::find accept pointer to const object? I guess partial template specialization was involved?

Answer 1

This is actually a quite interesting question about const-correctness and some non-intuitive errors, but the compiler is right in rejecting the code.

Why does is not work in Qt?

The compiler rejects the code because it would break const-correctness of the code. I don’t know the library, but I think I can safely assume that the signature of contains is QVector<T>::contains( T const & value )^[1], which in the case of T == type* means:

QVector<type *>::contains( type * const & value )

Now the problem is that you are trying to pass a variable of type type const *. The problem at this point is that the compiler does not know what contains does internally, only the promises it offers in it’s interface. contains promises not to change the pointer, but says nothing about the pointee. There is nothing in the signature inhibiting the implementation of contains from modifying the value. Consider this similar example:

void f( int * const & p ) { // I promise not to change p
   *p = 5;                  // ... but I can modify *p
}
int main() {
   const int k = 10;
   int const * p = &k;
   f( p );                  // Same problem as above: if allowed, f can modify k!!!
}

Why does it allow the similar call to std::find then?

The difference with std::find is that find is a template where the different argument type have a very loose coupling. The standard library does not perform type checking on the interface, but rather on the implementation of the template. If the argument is not of the proper type, it will be picked up while instantiating the template.

What this means is that the implementation will be something similar to:

template <typename Iterator, typename T>
Iterator find( Iterator start, Iterator end, T const & value ) {
   while ( start != end && *start != value )
      ++start;
   return start;
}

The type of the iterators and the value are completely unrelated, there is no constraint there other than those imposed by the code inside the template. That means that the call will match the arguments as Iterator == std::vector<type*>::iterator and T = type const *, and the signature will match. Because internally value is only used to compare with *start, and the comparison of type * and type const * const is valid (it will convert the former to the later and then compare ^[2]) the code compiles perfectly.

If the template had the extra restriction that the type of the second argument was Iterator::value_type const & (this could be implemented with SFINAE) then find would fail to compile with the same error.

^[1] Note the choice of ordering in the declaration: type const *, rather than const type *. They are exactly the same for the compiler (and the experienced eye), but by always adding the const to the right it makes it trivial to identify what is being defined as const, and to identify that const T & with T == type * in the argument of contains is not const type *&.

^[2] In the same way that you cannot bind a type * const & to a type const *, you cannot do the equivalent with pointers, type * const * cannot be converted from type const *, but if const is added to both the pointer and the pointee types, then the conversion is fine as it guarantees not to break const correctness. That conversion (which is safe) is performed in the comparison of type * == type const * const, where the left hand side gets two extra const: type const * const. If it is not clear why this does not break const-correctness, drop a comment and I will provide some code here.