В этой статье хотелось бы кратко рассмотреть особенности применения механизма обнаружения наличия функциональности у используемых типов данных на этапе компиляции.

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

Например, простейший код при компиляции выдаст такое количество строк текста, что смотреть и разбирать его не хочется (хотя, конкретно в этом примере не сложно разобраться):

class A {};

template <class T>
void print ( const T & value )
{
    std::cout << "value: " << value << std::endl;
}

int main ( int, char ** )
{
    print( A() );
    return 0;
}

Но если добавить в него обнаружение наличия необходимой функциональности, то всё становится намного понятнее.

template <class T>
std::enable_if_t< is_detected< LeftShiftOperator, std::ostream, T >(), void >
print ( const T & value ) {
    std::cout << "value: " << value << std::endl;
}

Еще одним случаем необходимости такой диагностики является пример, когда на этапе компиляции требуется выбрать, какой метод у объекта должен быть вызван:

template <class T>
void clear ( T & container )
{
    if constexpr ( is_detected< ClearMember, T >() )
        container.clear();
    else if ( is_detected< CleanMember, T >() )
        container.clean();
    else if ( is_detected< RemoveAllMember, T >() )
        container.removeAll();
}

В этих примерах можно было бы использовать концепты и рефлексию, но... В случае концептов их применение возможно только начиная с C++20 и их поддержка не везде реализована в полном объеме. А в случае с рефлексией маловероятно что её внедрение будет в C++23, если только в экспериментальных реализациях.

А что делать, если такая функциональность нужна прямо здесь и сейчас? Для этого пока что подойдет эксплуатация механизма SFINAE, который уже традиционно используется в делах рефлексии, а не только по своему прямому назначению. С помощью механизма SFINAE в стандартной библиотеке в type_traits уже определено большое количество средств обнаружения различных особенностей для типов. Более широкий набор инструментов определен в Boost.TypeTraits, в том числе средства обнаружения операторов с помощью boost::has_<operator_name> и boost::is_detected.

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

void foo ();

template <class T, class... Args>
struct DoesFooFunctionExistsHelper
{
private:
    template <class _Test, class = decltype(foo(std::declval<Args>() ...) )>
    static constexpr ::std::true_type __test(int);

    template <class>
    static constexpr ::std::false_type __test(...);

public:
    using type = decltype(__test<T>(std::declval<int>()));
};

template < typename ... _Arguments >
inline constexpr bool doesFooFunctionExists () { return DoesFooFunctionExistsHelper< void, _Arguments ... >::type::value; }

static_assert( doesFooFunctionExists<>(), "The function foo() was declared but not detected!" );

В этом случае компилятор выбирает подходящий метод __test, что позволяет косвенно диагностировать наличие желаемой функциональности. Но данный подход достаточно громоздкий и не наглядный в использовании.

Инструменты обнаружения

Замечательное предложение в стандарт N4502 (входит в состав Boost.TypeTraits), которое позволяет решить данную задачу весьма изящным способом. Не буду углубляться в техническую реализацию и принцип действия, они хорошо описаны в самом предложении N4502 и здесь. Углубимся в особенности его применения.

Предложение содержит реализацию детектора для поддержки следующих желаемых компонентов из набора средств обнаружения:

template <template<class...> class Op, class... Args>
using is_detected = ...; // std::true_type || std::false_type

template< template<class...> class Op, class... Args >
using detected_t = ...; // Op<Args...> || nonesuch

template< class Default, template<class...> class Op, class... Args >
using detected_or_t = ...; // Op<Args...> || Default

template <class Expected, template<class...> class Op, class... Args>
using is_detected_exact = std::is_same<detected_t<Op, Args...>, Expected>;

template <class To, template<class...> class Op, class... Args>
using is_detected_convertible = std::is_convertible<detected_t<Op, Args...>, To>;

Рассмотрим подробнее, каким образом этим набором средств обнаружения можно пользоваться.

Обнаружение функции

Предположим, имеется следующие определения функций foo

void foo();
int foo(int);

и требуется обнаружить их наличие с помощью представленных средств.

Для этого необходимо определить вспомогательный тип:

template <class... Args>
using FooFunction = decltype( foo( std::declval<Args>() ... ) );

Данное определение означает, что FooFunction<Args...> является типом, возвращаемым функцией с параметрами foo(Args...) . Для эмуляции вызова функции foo с параметрами используется вспомогательный метод std::declval, с описанием которого можно ознакомится здесь.

Используя это определение, можно обнаружить наличие функции foo следующим способом:

static_assert( is_detected< FooFunction >(), "The foo() was defined but not detected!" );
static_assert( is_detected< FooFunction, int >(), "The foo(int) was defined but not detected!" );
static_assert( !is_detected< FooFunction, int, double >(), "The foo(int,double) was not defined but detected!" );
static_assert( !is_detected< FooFunction, std::string >(), "The foo(string) was not defined but detected!" );

А так как FooFunction<Args...> является типом, возвращаемым функцией с параметрами foo(Args...), то в этом случае можно проверить и возвращаемый тип на идентичность и на конвертируемость:

static_assert( is_detected_exact< int, FooFunction, int >(), "The int foo(int) was defined but not detected!" );
static_assert( !is_detected_exact< double, FooFunction, int >(), "The double foo(int) was not defined but detected!" );
static_assert( is_detected_convertible< double, FooFunction, int >(), "The convertible int foo(int) was defined but not detected!" );      

Всё красиво и можно радоваться, но... Попробуем обнаружить функцию foo(double):

static_assert( is_detected< FooFunction, double >(), "The convenient foo(int) was defined but not detected!" ); // Oops!

И мы её обнаружили! Как же так?

Всё дело в том, что при определении FooFunction<Args...> использовалась имитация вызова функции foo с подходящими параметрами, а не с идентичными. Это значит, что если существует возможность вызова функции foo с учетом правил преобразования типов, то функция будет обнаружена.

Для строгого соответствия параметров при обнаружении функции следует использовать определение вида:

template <class... Args>
using StrictFooFunction = decltype( std::integral_constant< detected_t<FooFunction, Args...>(*)(Args...), (&foo) >::value( std::declval<Args>() ... ) );

Использование std::integral_constant позволяет гарантировать точное соответствие сигнатуры функции foo указанным типам для её параметров. Мы не указываем возвращаемый тип функции foo явно, поэтому задаем его с помощью типа detected_t<FooFunction, Args...>, который, как мы помним, и является типом, возвращаемым функцией с параметрами foo(Args...) или nonesuch.

В этом случае обнаружение функции будет происходить строго в соответствии с сигнатурой:

static_assert( is_detected< StrictFooFunction, int >(), "The foo(int) was defined but not detected!" );
static_assert( is_detected< StrictFooFunction, double >(), "The foo(double) was not defined but detected!" );

Есть несколько ограничений при обнаружении функций.

Если определение функции foo будет произведено после определения типа FooFunction<Args...>, то она не будет обнаружена.

template <class... Args>
using FooFunction = decltype( foo( std::declval<Args>() ... ) );

int foo(int);

template <class... Args>
using OtherFooFunction = decltype( foo( std::declval<Args>() ... ) );

static_assert( !is_detected< FooFunction, int >(), "The foo(int) was not defined before FooFunction but detected!" );
static_assert( is_detected< OtherFooFunction, int >(), "The foo(int) was defined before OtherFooFunction but not detected!" );

Если до определения типа StrictFooFunction<Args...> не будет произведено ни одной декларации функции foo, то возникнет ошибка компиляции.

Обнаружение метода структуры или класса

Пусть имеется следующая декларация

struct A
{
    void foo();
    int foo(int) const;
    static void foo(int, int);
};

и требуется обнаружить наличие метода foo.

Как и в случае для функции можно обнаружить метод с подходящими параметрами или с их строгим соответствием. При этом учитываются также квалификаторы доступа к функциям const и volatile.

Для обнаружения метода с подходящими параметрами необходимо определить тип:

template <class T, class... Args>
using FooMember = decltype(std::declval<T>().foo(std::declval<Args>() ...));

Данное определение означает, что FooMember<Args...> является типом, возвращаемым функцией с параметрами T::foo(Args...) . Используя это определение, можно обнаружить наличие методаfoo следующим способом:

static_assert( is_detected< FooMember, A >(), "The member A::foo() was declared but not detected!" );
static_assert( !is_detected< FooMember, A const >(), "The member A::foo() const was not declared but detected!" );
static_assert( is_detected< FooMember, A, int >(), "The member A::foo(int) const was declared but not detected!" );
static_assert( is_detected< FooMember, A const, double >(), "The convenient member A::foo(int) const was declared but not detected!" );
static_assert( is_detected< FooMember, A, int, int >(), "The static member A::foo(int,int) was declared but not detected!" );

Для обнаружения метода в строгом соответствии с сигнатурой есть нюансы.

Если требуется обнаружить наличие статического метода в соответствии со строгой сигнатурой, то достаточно использовать определение типа, как для функции:

template <class T, class... Args>
using StrictFooStaticMember = decltype( std::integral_constant<detected_t<FooMember, T, Args ...>(*)(Args ...), &std::decay_t<T>::foo >::value(std::declval<Args>() ...) );

В этом случае обнаружение будет выглядеть так:

static_assert( is_detected< StrictFooStaticMember, A, int, int >(), "The static member void A::foo(int,int) was declared but not detected!" );
static_assert( !is_detected< StrictFooStaticMember, A, int&, int& >(), "The static member void A::foo(int&,int&) was not declared but detected!" );

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

namespace detail
{
    template <class T, class M>
    struct member_signature;
    template <class T, class R, class... Args>
    struct member_signature< T, R( Args ...) > { using type = R(std::decay_t<T>::*)(Args ...); };
    template <class T, class R, class... Args>
    struct member_signature< T const, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) const; };
    template <class T, class R, class... Args>
    struct member_signature< T const &, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) const &; };
    template <class T, class R, class... Args>
    struct member_signature< T const &&, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) const &&; };
    template <class T, class R, class... Args>
    struct member_signature< T volatile, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) volatile; };
    template <class T, class R, class... Args>
    struct member_signature< T volatile &, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) volatile &; };
    template <class T, class R, class... Args>
    struct member_signature< T volatile &&, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) volatile &&; };
    template <class T, class R, class... Args>
    struct member_signature< T const volatile, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) const volatile; };
    template <class T, class R, class... Args>
    struct member_signature< T const volatile &, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) const volatile &; };
    template <class T, class R, class... Args>
    struct member_signature< T const volatile &&, R(Args ...) > { using type = R(std::decay_t<T>::*)(Args ...) const volatile &&; };
}

template <class T, class Sign >
using member_signature_t = typename detail::member_signature< T, Sign >::type;

В этом случае определение вспомогательного типа для обнаружения не статического метода будет выглядеть так:

template <class T, class... Args>
using StrictFooMember = decltype( (std::declval<T>() .* std::integral_constant< member_signature_t<T, detected_t<FooMember, T, Args ...>(Args ...)>, &std::decay_t<T>::foo>::value)(std::declval<Args>() ...) );

Конструкция выглядит устрашающей). Но по сути своей эмулирует попытку вызова метода T::foo(Args ...) по её адресу с проверкой сигнатуры с помощью применения std::integral_constant.

Обнаружение наличия метода с помощью StrictFooMember будет выглядеть уже привычным способом:

static_assert( is_detected< StrictFooMember, A >(), "The member A::foo() was declared but not detected!" );
static_assert( !is_detected< StrictFooMember, A, int >(), "The member A::foo(int) was not declared but detected!" );
static_assert( is_detected< StrictFooMember, A const, int >(), "The member A::foo(int) const was declared but not detected!" );
static_assert( !is_detected< StrictFooMember, A const, double >(), "The member A::foo(double) const was not declared but detected!" );

Описанные ранее ограничения при обнаружении функций не распространяются на обнаружение членов класса. Единственным ограничением обнаружения членов класса является публичный доступ к ним.

Проверка возвращаемого типа на идентичность и на конвертируемость для всех представленных определений может быть произведена с помощью функций is_detected_exact и is_detected_convertible.

Выводы

Набор инструментов обнаружения функциональности на этапе компиляции, представленные в предложении в стандарт N4502, позволяют достаточно гибко обнаруживать наличие методов, как подходящих, так и строго соответствующих заданной сигнатуре.

Данный механизм может быть использован как альтернатива элементам концептов и рефлексии там, где последние еще не реализованы.

PS

Надеюсь, что кому-то помог разобраться в нюансах использования представленного инструмента обнаружения функциональности.

Детальный пример использования подобного подхода представлен в моем проекте инструментов ScL (Detection). Также этот подход применяется при рефлексии операторов для класса-обертки, представленной в статье "Добавляем дополнительные особенности реализации на C++ с помощью «умных» оберток".