Почему make_tie не вещь?

Question

Существует популярная идиома, использующая std::tie для реализации операторов сравнения:

// foo.h
struct Foo {
  int a, b;
  string c;

  bool operator<(const Foo& rhs) const;
};

// foo.cc
bool Foo::operator<(const Foo& rhs) const {
  return tie(a, b, c) < tie(rhs.a, rhs.b, rhs.c);
}

например. широко используется в хроме

Однако это требует копирования списка членов, так почему бы не написать вспомогательную функцию:

static auto MakeTie(const Foo& x) {
  return tie(x.a, x.b, x.c);
}
bool Foo::operator<(const Foo& rhs) const {
  return MakeTie(*this) < MakeTie(rhs);
}

// or, in foo.h
auto MakeTie() const;
// and in foo.cc
auto Foo::MakeTie() const { ... }

(кстати, такая функция-член не может быть вызвана из любой другой единицы перевода)

Итак, почему я вижу сотни таких tie(a, b, c) < tie(copy-pasta) пар, есть ли причина этого?

Answer 1

Во-первых, если в вашем классе так много учеников, что удвоение tie проблематично, то в любом случае у вас может быть дизайнерский запах.

Я будет склонен соглашаться с тем, что это немного раздражает, но помните, что это не причина существования tie. Нет такой вещи как "tie"; «связать» здесь - это глагол, способ описать, как выражения «связываются» в то, что на самом деле является кортежем ссылок.

Вы, конечно, можете написать собственную замену для tie, которая знает, как работают все соответствующие члены вашего класса, так что для этого не нужно выписывать дважды. Вы могли бы назвать это members_as_tuple. Вам решать, хотите ли вы сделать это, так же, как и вам, стоит ли делать любую функцию, чтобы избежать какого-то конкретного дублированного кода.

Конечно, хотя, без размышлений, C ++ не может сделать это для вас в общем случае, поэтому такая возможность не предоставляется "из коробки".

tl; dr: Вы уже показали лучший (только?) Способ сделать это, но я бы не назвал это make_tie.

---

Что касается того, почему люди не делают этого больше, ну, это неопровержимо. Они, вероятно, просто не думали об этом или не думали, что им это нужно, и, вероятно, были правы.