Implementing comparison operators via 'tuple' and 'tie', a good idea?

111
votes

(Note: tuple and tie can be taken from Boost or C++11.)
When writing small structs with only two elements, I sometimes tend to choose a std::pair, as all important stuff is already done for that datatype, like operator< for strict-weak-ordering.
The downsides though are the pretty much useless variable names. Even if I myself created that typedef, I won't remember 2 days later what first and what second exactly was, especially if they are both of the same type. This gets even worse for more than two members, as nesting pairs pretty much sucks.
The other option for that is a tuple, either from Boost or C++11, but that doesn't really look any nicer and clearer. So I go back to writing the structs myself, including any needed comparision operators.
Since especially the operator< can be quite cumbersome, I thought of circumventing this whole mess by just relying on the operations defined for tuple:

Example of operator<, e.g. for strict-weak-ordering:

bool operator<(MyStruct const& lhs, MyStruct const& rhs){
  return std::tie(lhs.one_member, lhs.another, lhs.yet_more) <
         std::tie(rhs.one_member, rhs.another, rhs.yet_more);
}

(tie makes a tuple of T& references from the passed arguments.)

Edit: The suggestion from @DeadMG to privately inherit from tuple isn't a bad one, but it got quite some drawbacks:

  • If the operators are free-standing (possibly friends), I need to inherit publicly
  • With casting, my functions / operators (operator= specifically) can be easily bypassed
  • With the tie solution, I can leave out certain members if they don't matter for the ordering

Are there any drawbacks in this implementation that I need to consider?

4
c++c++11operatorstuplesstrict-weak-ordering
Looks perfectly reasonable to me... - ildjarn
That's a very clever idea, even if it doesn't pan out. I'm going to have to investigate this. - templatetypedef
I like this idea! If the tie(...) calls are going to be duplicated in various operators (=, ==, <, etc.) you could write a private inline method make_tuple(...) to encapsulate that and then call it from the various other places, as in return lhs.make_tuple() < rhs.make_tuple(); (though the return type from that method could be fun to declare!) - aldo
@aldo: C++14 to the rescue! auto tied() const{ return std::tie(the, members, here); } - Xeo
It makes it more readable and easier but one concern is strings. Will this result in two operators being called for string ? The string::compare can be used to only do the comparison once and not iterate through strings twice. Worst case with tuple the strings may be iterated through twice to check equality. - steviekm3

4 Answers

66
votes

This is certainly going to make it easier to write a correct operator than rolling it yourself. I'd say only consider a different approach if profiling shows the comparison operation to be a time-consuming part of your application. Otherwise the ease of maintaining this should outweigh any possible performance concerns.

5
votes

I have come accross this same problem and my solution uses c++11 variadic templates. Here comes the code:

The .h part:

/***
 * Generic lexicographical less than comparator written with variadic templates
 * Usage:
 *   pass a list of arguments with the same type pair-wise, for intance
 *   lexiLessthan(3, 4, true, false, "hello", "world");
 */
bool lexiLessthan();

template<typename T, typename... Args>
bool lexiLessthan(const T &first, const T &second, Args... rest)
{
  if (first != second)
  {
    return first < second;
  }
  else
  {
    return lexiLessthan(rest...);
  }
}

And the .cpp for the base case without arguments:

bool lexiLessthan()
{
  return false;
}

Now your example becomes:

return lexiLessthan(
    lhs.one_member, rhs.one_member, 
    lhs.another, rhs.another, 
    lhs.yet_more, rhs.yet_more
);
3
votes

In my opinion, you're still not addressing the same issue as the std::tuple solves- namely, you have to know both how many and the name of each member variable, you're duplicating it twice in the function. You could opt for private inheritance.

struct somestruct : private std::tuple<...> {
    T& GetSomeVariable() { ... }
    // etc
};

This approach is a little bit more of a mess to begin with, but you're only maintaining the variables and names in one place, instead of in every place for every operator you wish to overload.

1
votes

If you plan to use more than one operator overload, or more methods from tuple, I'd recommend making tuple a member of the class or derive from tuple. Otherwise, what you're doing is a lot more work. When deciding between the two, an important question to answer is: Do you want your class to be a tuple? If not I would recommend containing a tuple and limiting the interface by using delegation.

You could create accessors to "rename" the members of the tuple.