constexpr перегрузка

Я согласен, что этой функции нет - она ​​мне тоже нужна. Пример:

double pow(double x, int n) {
    // calculate x to the power of n
    return ...
}

static inline double pow (double x, constexpr int n) {
    // a faster implementation is possible when n is a compile time constant
    return ...
}

double myfunction (double a, int b) {
    double x, y;
    x = pow(a, b);  // call version 1 unless b becomes a compile time constant by inlining
    y = pow(a, 5),  // call version 2
    return x + y;
}

Теперь мне нужно сделать это с помощью шаблонов:

template <int n>
static inline double pow (double x) {
    // fast implementation of x ^ n, with n a compile time constant
    return ...
}

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

Изменить: трюк, описанный ниже, больше не работает!

Обнаружение constexpr не может быть выполнено с использованием перегрузок (как и другие уже ответили), но перегрузки - лишь один из способов сделать это.

Типичная проблема заключается в том, что мы не можем использовать что-то, что может улучшить производительность во время выполнения (например, для вызова функций, отличных от constexpr, или для кеширования результатов) в функции constexpr. Таким образом, мы можем получить два разных алгоритма: один менее эффективен, но доступен для записи как constexpr, а другой оптимизирован для быстрой работы, но не constexpr. Затем мы хотим, чтобы компилятор не выбирал алгоритм constexpr для значений времени выполнения и наоборот.

Это может быть достигнуто путем обнаружения constexpr и выбора на его основе «вручную», а затем сокращения интерфейса с помощью макросов препроцессора.

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

#include <iostream>     // handy for test I/O
#include <type_traits>  // handy for dealing with types

// run-time "foo" is always ultimate answer
int foo_runtime(int)
{
    return 42;
}

// compile-time "foo" is factorial
constexpr int foo_compiletime(int num)
{
      return num > 1 ? foo_compiletime(num - 1) * num : 1;
}

Затем нам нужен способ определить, что аргумент является выражением константы времени компиляции. Если мы не хотим использовать специфичные для компилятора способы, такие как __builtin_constant_p, то есть способы обнаружить это и в стандартном C ++. Я почти уверен, что следующий трюк придумал Йоханнес Шауб, но я не могу найти ссылку. Очень красивый и понятный трюк.

template<typename T> 
constexpr typename std::remove_reference<T>::type makeprval(T && t) 
{
    return t;
}

#define isprvalconstexpr(e) noexcept(makeprval(e))

Оператор noexcept необходим для работы во время компиляции, поэтому основанное на нем ветвление будет оптимизировано большинством компиляторов. Итак, теперь мы можем написать макрос "foo", который выбирает алгоритм на основе constexprness аргумента и проверяет его:

#define foo(X) (isprvalconstexpr(X)?foo_compiletime(X):foo_runtime(X))

int main(int argc, char *argv[])
{
    int a = 1;
    const int b = 2;
    constexpr int c = 3;
    const int d = argc;

    std::cout << foo(a) << std::endl;
    std::cout << foo(b) << std::endl;
    std::cout << foo(c) << std::endl;
    std::cout << foo(d) << std::endl;
}

Ожидаемый результат:

42
2
6
42

На нескольких компиляторах, которые я пробовал, он работает, как ожидалось.

Он должен быть перегружен на основе результата constexpr или нет, а не аргументов.

const std::string может хранить указатель на литерал, зная, что он никогда не будет записан (потребуется использование const_cast для удаления const из std::string, а это уже неопределенное поведение). Было бы просто необходимо сохранить логический флаг, чтобы запретить освобождение буфера во время разрушения.

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

Согласно стандарту (раздел 7.1.6.1 [dcl.type.cv]) изменение любого объекта, который был создан const, является неопределенным поведением:

За исключением того, что любой член класса, объявленный изменяемым (7.1.1), может быть изменен, любая попытка изменить константный объект во время его жизни (3.8) приводит к неопределенному поведению.

Хотя в C ++ 11 нет такой вещи, как «перегрузка constexpr», вы все равно можете использовать GCC / Clang __builtin_constant_p intrinsic. Обратите внимание, что эта оптимизация не очень полезна для double pow(double), потому что и GCC, и Clang уже могут оптимизировать pow для постоянных целочисленных показателей, но если вы напишете мультиточную или векторную библиотеку, эта оптимизация должна работать.

Посмотрите этот пример:

#define my_pow(a, b) (__builtin_constant_p(b) ? optimized_pow(a, b) : generic_pow(a, b))

double generic_pow(double a, double b);

__attribute__((always_inline)) inline double optimized_pow(double a, double b) {
    if (b == 0.0) return 1.0;
    if (b == 1.0) return a;
    if (b == 2.0) return a * a;
    if (b == 3.0) return a * a * a;
    if (b == 4.0) return a * a * a * a;

    return generic_pow(a, b);
}

double test(double a, double b) {
    double x = 2.0 + 2.0;
    return my_pow(a, x) + my_pow(a, b);
}

В этом примере my_pow(a, x) будет расширен до a*a*a*a (благодаря устранению мертвого кода), а my_pow(a, b) будет расширен до прямого вызова generic_pow без каких-либо предварительных проверок.

Проблема, как уже говорилось, кажется неправильной.

std::string, по построению, владеет памятью. Если вам нужна простая ссылка на существующий буфер, вы можете использовать что-то вроде llvm::StringRef:

class StringRef {
public:
  constexpr StringRef(char const* d, size_t s): data(d), size(s) {}

private:
  char const* data;
  size_t size;
};

Конечно, есть облом, что strlen и все остальные функции C не constexpr. Это похоже на дефект Стандарта (подумайте обо всех математических функциях ...).

Что касается состояния, вы можете (немного), если вы понимаете, как его хранить. Помните, что циклы эквивалентны рекурсиям? Точно так же вы можете «сохранить» состояние, передав его в качестве аргумента вспомогательной функции.

// potentially unsafe (non-limited)
constexpr int length(char const* c) {
  return *c == '\0' ? 0 : 1 + length(c+1);
}

// OR a safer version
constexpr int length_helper(char const* c, unsigned limit) {
  return *c == '\0' or limit <= 0 ? 0 : 1 + length_helper(c+1, limit-1);
}

constexpr int length256(char const* c) { return length_helper(c, 256); }

Конечно, эта форма этого состояния несколько ограничена (нельзя использовать сложные конструкции), и это ограничение constexpr. Но это уже огромный шаг вперед. Идти дальше означало бы углубиться в чистоту (что вряд ли возможно в C ++).

Возможно ли, чтобы реализация C ++ 11, соответствующая стандарту, разрешила перегрузку функций на основе аргументов constexpr, или это потребует обновления стандарта? Если это не разрешено, было ли это сделано намеренно?

Если в стандарте не сказано, что вы можете что-то делать, то позволять кому-то это делать было бы нестандартным поведением. И поэтому компилятор, который позволил бы это реализовать, будет реализовывать расширение языка.

В конце концов, это не обязательно плохо. Но это было бы несовместимо с C ++ 11.

О намерениях комитета по стандартам можно только догадываться. Возможно, они сознательно не допустили этого, или это могло быть что-то вроде недосмотра. Дело в том, что стандарт не допускает перегрузок, следовательно, не допускается.

Другой вариант обнаружения компиляции во время компиляции с помощью SFINAE: http://coliru.stacked-crooked.com/a/f3a2c11bcccdb5bf

template<typename T>
auto f(const T&)
{
  return 1;
}

constexpr auto f(int)
{
  return 2;
}



////////////////////////////////////////////////////////////////////////
template<typename T, int=f(T{})>
constexpr bool is_f_constexpr_for(int) {return true;}

template<typename...>
constexpr bool is_f_constexpr_for(...) {return false;}



template<typename T>
auto g(const T& t)
{
  if constexpr (is_f_constexpr_for<T>(0))
  {

  }
  else
  {

  }
}

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

Мы можем присвоить unsigned int consexpr неотрицательный int без сужения:

unsigned int u {std::max(0, -3)}; // compiles, max is constexpr

Однако мы не сможем сделать это, если будем использовать переменную:

int a = 3;
unsigned int u {std::max(0, a)}; // compilation error, narrowing int to unsigned int

Чтобы определить, является ли данное int reference константным выражением, мы можем проверить, может ли оно быть присвоено unsigned int без сужения с положительным или отрицательным значением. Это должно быть возможно для любого int, значение которого известно во время компиляции, т.е. может рассматриваться как постоянное выражение.

template<const int& p> std::true_type
    is_constexpr_impl(decltype((unsigned int){std::max(-p, p)}));
template<const int& p> std::false_type
    is_constexpr_impl(...);
template<const int& p> using is_constexpr =
    decltype(is_constexpr_impl<p>(0));

Теперь у нас могут быть разные реализации для времени выполнения и времени компиляции с помощью макроса:

int foo_runtime(int num) {
    return num;
}

constexpr int foo_compiletime(int num) {
      return num + 1;
}

#define foo(X) (is_constexpr<X>()?foo_compiletime(X):foo_runtime(X))

И, как уже говорилось, он имитирует перегрузку для выражения const:

int main() {
    static int a = 3;
    static const int b = 42; // considered constexpr
    static const int c = foo_runtime(42); // not constexpr
    static constexpr int d = 4;
    static constexpr int e = -2;
    static int f = 0;
    static const int g = 0; // considered constexpr

    std::cout << foo(a) << std::endl;
    std::cout << foo(b) << std::endl;
    std::cout << foo(c) << std::endl;
    std::cout << foo(d) << std::endl;
    std::cout << foo(e) << std::endl;
    std::cout << foo(f) << std::endl;
    std::cout << foo(g) << std::endl;
}

Вышеизложенный вариант хорош, но не очень полезен, поскольку он ограничен переменными статическим хранилищем. Но есть перегрузка на основе constexpr.

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

template<const int& p> std::true_type
    is_constexpr_impl(std::array<int, std::max(p, -p)>);
template<const int& p> std::false_type
    is_constexpr_impl(...);
template<const int& p> using is_constexpr = 
    decltype(is_constexpr_impl<p>(0));

Использование std::array выше заменяет использование простого c-массива, , который не подходит для gcc с этим подходом.

Или другой - опять же, не полагаясь на правила сужения - , который также отлично работает:

template<const int& p, typename T = void>
struct is_constexpr: std::false_type {};

template<const int& p>
struct is_constexpr<p, std::void_t<int[std::max(p,-p)+1]>>: std::true_type {};

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

template<typename T>
struct is_constexpr: std::false_type {};

template<typename T>
struct is_constexpr<const T>: std::true_type {};

#define foo(X) (is_constexpr<decltype(X)>()?foo_compiletime(X):foo_runtime(X))

Мы не достигли нашей цели по этой строке:

static const int c = foo_runtime(42); // const but not constexpr