Less than operator through implicit conversion?

Question

Consider the following class:

struct C 
{
     /* Class contents, without any arithmetic operator... */
     constexpr operator int() noexcept; // Implicit conversion to int
};

My question is:

• Is C usable in standard algorithms like std::sort that currently uses the default < operator?
• Is C considered as satisfying the LessThanComparable concept?
• Will C meet the requirements of an hypothetical conceptified algorithm library that would require the type to be LessThanComparable.

Answer 1

Is C usable in standard algorithms like std::sort that currently uses the default < operator?

Yes, it works for std::sort() and some other standard algorithms. The code

#include <algorithm>
#include <vector>

struct C 
{
     /* Class contents, without any arithmetic operator... */
     constexpr operator int() noexcept {return 0;} // Implicit conversion to int
};

int main()
{
    std::vector<C> v;  
    std::sort( begin(v), end(v) );
}

compiles. Here's a live demo. Look at the next question though!

Is C considered as satisfying the LessThanComparable concept?

No. The requirements of the LessThanComparable concept are, that for objects x and y of type C or const C the expression x<y is valid and implicitly convertible to bool and the < operator establishes a strict weak ordering relation. In your case const objects do will not convert to ints. This is a bug in your code, because it is not const correct. Adding the const keyword will make it work and the class C would indeed be LessThanComparable. The strict weak ordering relation is fulfilled, because ints fulfil this requirement.

Will C meet the requirements of an hypothetical conceptified algorithm library that would require the type to be LessThanComparable.

If you fix your constness, yes, it will.

A few sidenotes:

• GCC 4.9 compiles x<y even if x and y are of type const C. This seems to be a compiler bug, since GCC 5.2 and clang 3.6 throw a compile time error here.

• Passing std::less<C>() as an extra argument to std::sort() gives a compile time error, because the compare function requires constant objects to be comparable in that case. However, passing std::less<void>() doesn't break anything, since arguments are perfectly forwarded.

• The std::sort() algorithm does not require a full LessThanComparable, but the concept Compare. Furthermore, the iterator type must be a RandomAccessIterator that is ValueSwappable and the dereferenced type must be MoveContructable and MoveAssignable. This is all the case for your first question, even when the constness bug is not fixed. That's why std::sort() and other standard algorithms work.

Answer 2

No. Compiler cannot do so big magic, i.e. calling the cast method and then applying < operator. Imagine there are several cast operators for different types, how would the compiler choose the proper one?

EDIT: Actually it's not correct. As long as there is single cast operator, this will work. But with two or more the compiler will complain about ambiguous cast. However, this approach is highly fragile so in general it's not good idea.

Answer 3

I tried the example proposed by mehrdad momeny. It worked fine. However, with little editing, it is not working anymore.

#include <iostream>
#include <string>
#include <vector>
#include <algorithm>

struct C 
{
    C(int x):X(x){}
    operator int() { return X; }
    operator float() { return static_cast<float>(X); }

    int X;
};

using namespace std;

int main()
{
    vector<C> u = {1, 2, 35, 6, 3, 7, 8, 9, 10};
    sort(u.begin(), u.end());
    for(auto x: u){
        cout << x << endl;
    }
}

Live Demo

Because this will lead to an ambiguity. So, it is not a good idea to to do it like this.