Проверка нескольких значений при использовании операторов сравнения

#include <algorithm>
#include <array>
#include <string>
#include <iostream>
#include <initializer_list>
 
template<class Type, class Next>
bool is_one_of(const Type& needle, const Next& next)
{return needle==next;}
template<class Type, class Next, class ... Rest>
bool is_one_of(const Type& needle, const Next& next, Rest... haystack)
{return needle==next || is_one_of(needle, haystack...);}
 
int main() {
    std::string X, Y;
    if (is_one_of(X, Y, "HI"))
        std::cout << "it is!";
    else
        std::cout << "it isn't!";
    return 0;
}

доказательство компиляции. Xeo также отмечает, что std::any_of, std::all_of и std::none_of могут быть полезны в зависимости от ваших реальных потребностей и желаний.

Нет чистого способа сделать то, что вы просите, на С++.

Многих сбивает с толку то, что X == (Y || Z) может быть допустимым выражением, и компилятор не будет жаловаться. Это будет просто ошибка. Каждый оператор C++ должен оцениваться как истина/ложь сам по себе, а операторы просто связывают их вместе. То, что вы предлагаете, потребует некоторой внутренней структуры списка. Это есть во многих языках (например, в Python), но не в C++.

С перегрузкой операторов вы можете получить именно тот синтаксис, который вам нужен. Но, как указывает Адам, это может привести к исключению правильных выражений.

Ниже приведен шаблон с перегрузкой оператора, функцией шаблона и макросом для достижения синтаксиса, похожего на более приятное решение Mooing Duck, но не требующего C++11 и позволяющего использовать оператор || для обозначения коллекции «стог сена».

template <typename T>
struct MultiOrComparable {
    mutable std::set<T> vals;
    const MultiOrComparable & operator || (T v) const {
        vals.insert(v); return *this;
    }
    bool operator == (T v) const { return vals.find(v) != vals.end(); }
};

template <typename T>
MultiOrComparable<T> MultiOrComparableStart (T) {
    return MultiOrComparable<T>();
}

#define IsOneOf(x, y) ((MultiOrComparableStart(x)||y) == x)

Затем «работает» следующая программа:

enum Foo { A, B, C, D };

int
main ()
{
    if (!IsOneOf(A, B || C || D)) {
        std::cout << "!=" << std::endl;
    }
    if (IsOneOf('a', 'x' || 'y' || 'z' || 'a')) {
        std::cout << "==" << std::endl;
    }
}

Может быть способ добиться того, чего вы хотите, с помощью шаблонов выражений. Ниже приведен набросок того, как к этому подойти (не компилируется, отсутствует много деталей, предупредите лектора). Сначала вы настраиваете шаблон класса для представления логических значений и определяете над ними некоторые операторы.

template<typename T, typename Type = Atomic<T> >
class Logical;

template<typename T, typename E1, typename E2>
Logical<T, OpOr<T, E1, E2> > operator||(Logical<T, E1> lhs, Logical<T, E2> rhs); 

template<typename T, typename E1, typename E2>
Logical<T, OpAnd<T, E1, E2> > operator&&(Logical<T, E1> lhs, Logical<T, E2> rhs); 

template<typename T, typename E1, typename E2>
Logical<T, OpEq<T, E1, E2> > operator==(Logical<T, E1> lhs, Logical<T, E2> rhs)
{ return OpEq<T, E1, E2>()(lhs, rhs); } // delegate to class template

Поскольку шаблоны функций не могут быть частично специализированными, вы делегируете фактическую работу шаблонам классов.

// primary template
template<typename T, typename E1, typename E2> class OpEq; 

// specialization for atomic comparisons
template<typename T>
class OpEq<T, Atomic<T>, Atomic<T> >
{
    bool operator()(Atomic<T> lhs, Atomic<T> rhs)
    { return lhs == rhs; }
}

// apply distributive rule
template<typename T>
class OpEq<T, Atomic<T>, OpOr<T, Atomic<T>, Atomic<T> > >
{
    bool operator()(Atomic<T> lhs, OpOr<T, Atomic<T>, Atomic<T> > rhs)
    { return (lhs == rhs.first()) && (lhs == rhs.second()); }
}

Очевидно, что для получения естественного синтаксиса C++ для того, что вы хотите, требуется много тяжелой техники шаблонов. Но, приложив много усилий и прочитав, вы можете в конечном итоге получить что-то хорошее. (Вам нужно будет определить Atomic, OpAnd, OpOr, настроить представления, содержащие первую и вторую ветви подвыражения и т.д. и т.д.)

Однако, даже если бы вам это удалось, вы бы получили действительно странную семантику в своей схеме. То, что вы предлагаете, требует, чтобы == было левораспределительным по сравнению с || или &&. т.е. разбирать

X == (Y @OP Z) 

as

(X == Y) @OP (X == Z)

где @OP равно && или ||. Я думаю, было бы естественно потребовать, чтобы == оставался симметричным. Это потребует от вас также наложить право-распределение == на && и ||. т.е. разбирать

(X @OP Y) == Z 

as

(X == Z) @OP (Y == Z)

Однако, если вы объедините их с выражением (A @OP1 B) == (C @OP2 D), вы получите логические несоответствия. Например. результат зависит от порядка, в котором вы применяете левое и правое распределение.

Слева-направо:

(A @OP1 B) == (C @OP2 D)
((A @OP1 B) == C) @OP2 ((A @OP1 B) == D)
((A == C) @OP1 (B ==C)) @OP2 ((A == D) @OP1 (B == D))

Направо-налево:

(A @OP1 B) == (C @OP2 D)
(A == (C @OP2 D)) @OP1 (B == (C @OP2 D))
((A == C) @OP2 (A == D)) @OP1 ((B == C) @OP2 (B == D))

В обоих случаях сравниваются одни и те же 4 пары элементов, но способ их распространения вверх по дереву выражений немного отличается. Если @OP1 и @OP2 совпадают, вы можете сгладить все дерево и изменить порядок членов, чтобы получить уникальный результат. , это работает нормально, если вы используете одни и те же операторы с обеих сторон ==, потому что и &&, и || являются ассоциативными, а также коммутативными.

Но для смешанных операторов результирующие выражения, вообще говоря, будут другими.

ОБНОВЛЕНИЕ: как упоминалось в комментариях к этому и другим ответам, вы также теряете определенные свойства встроенных типов. Во-первых, правила короткого замыкания, которым не следуют перегруженные операторы. Для логических выражений, не связанных с разыменованием указателя или другим доступом к ресурсам (if(p && p->value()) или if(file && file.open()) и т. д.), это не повлияет на правильность, а только на эффективность. В противном случае будьте осторожны! Во-вторых, было также упомянуто, что смешанные оценки констант/выражений будут ошибочными. У этого есть простое (но многословное) исправление: просто используйте std::integral_constant (или boost::mpl::int_) в качестве оболочки.