F.2 — Funkcje Constexpr (część 2)

Funkcja Constexpr wywołuje niewymagane wyrażenia stałe

Można się spodziewać, że funkcja constexpr będzie oceniana w czasie kompilacji, jeśli to możliwe, ale niestety tak nie jest.

W lekcji 5.5 -- Wyrażenia stałe zauważyliśmy, że w kontekstach, które nie wymagają wyrażenia stałego, kompilator może zdecydować, czy ma oceniać wyrażenie stałe w czasie kompilacji lub w czasie wykonywania. W związku z tym każde wywołanie funkcji constexpr, które jest częścią niewymaganego wyrażenia stałego, może zostać ocenione zarówno w czasie kompilacji, jak i w czasie wykonywania.

Na przykład:

#include <iostream>

constexpr int getValue(int x)
{
    return x;
}

int main()
{
    int x { getValue(5) }; // may evaluate at runtime or compile-time
    
    return 0;
}

W powyższym przykładzie, ponieważ getValue() jest constexpr, wywołanie getValue(5) jest wyrażeniem stałym. Jednakże, ponieważ zmienna x nie jest constexpr, nie wymaga inicjatora wyrażenia stałego. Mimo że udostępniliśmy inicjator wyrażenia stałego, kompilator może wybrać, czy getValue(5) wykonuje ocenę w czasie wykonywania, czy w czasie kompilacji.

Diagnostyka funkcji constexpr w wymaganych wyrażeniach stałych

Kompilator jest nie wymagany do określenia, czy funkcja constexpr jest możliwa do oceny w czasie kompilacji, dopóki nie zostanie faktycznie oceniona w czasie kompilacji. Dość łatwo jest napisać funkcję constexpr, która pomyślnie się kompiluje do użytku w czasie wykonywania, ale następnie nie udaje się jej skompilować, gdy jest oceniana w czasie kompilacji.

Głupi przykład:

#include <iostream>

int getValue(int x)
{
    return x;
}

// This function can be evaluated at runtime
// When evaluated at compile-time, the function will produce a compilation error
// because the call to getValue(x) cannot be resolved at compile-time
constexpr int foo(int x)
{
    if (x < 0) return 0; // needed prior to adoption of P2448R1 in C++23 (see note below)
    return getValue(x);  // call to non-constexpr function here
}

int main()
{
    int x { foo(5) };           // okay: will evaluate at runtime
    constexpr int y { foo(5) }; // compile error: foo(5) can't evaluate at compile-time

    return 0;
}

W powyższym przykładzie, gdy foo(5) jest używany jako inicjator zmiennej x, zostanie ona oceniona w czasie wykonywania. Działa to dobrze i zwraca wartość 5.

Jednakże, gdy foo(5), jest używana jako inicjator zmiennej constexpr y, musi zostać oceniona w czasie kompilacji. W tym momencie kompilator ustali, że wywołanie foo(5) nie może zostać ocenione w czasie kompilacji, ponieważ getValue() nie jest funkcją constexpr.

Dlatego pisząc funkcję constexpr, zawsze jawnie sprawdzaj, czy się ona kompiluje, gdy jest oceniana w czasie kompilacji (wywołując ją w kontekście, w którym wymagane jest wyrażenie stałe, na przykład podczas inicjalizacji constexpr zmienna).

Parametry funkcji Constexpr/consteval nie są constexpr

Parametry funkcji constexpr nie są domyślnie constexpr ani nie mogą być deklarowane as constexpr.

Ponieważ takie parametry nie są constexpr, nie można ich używać w wyrażeniach stałych w funkcji.

consteval int goo(int c)    // c is not constexpr, and cannot be used in constant expressions
{
    return c;
}

constexpr int foo(int b)    // b is not constexpr, and cannot be used in constant expressions
{
    constexpr int b2 { b }; // compile error: constexpr variable requires constant expression initializer

    return goo(b);          // compile error: consteval function call requires constant expression argument
}

int main()
{
    constexpr int a { 5 };

    std::cout << foo(a); // okay: constant expression a can be used as argument to constexpr function foo()
    
    return 0;
}

W powyższym przykładzie funkcja parametr b nie jest constexpr (mimo że argument a jest wyrażeniem stałym). Oznacza to, że b nie można użyć wszędzie tam, gdzie wymagane jest wyrażenie stałe, na przykład w inicjatorze zmiennej constexpr (np. b2) lub w wywołaniu funkcji constexpr (goo(b)).

Parametry funkcji constexpr można zadeklarować jako const, w którym to przypadku są one traktowane jako stałe czasu wykonania.

Funkcje Constexpr są domyślnie wbudowane

Gdy funkcja constexpr jest oceniana w czasie kompilacji, kompilator musi być w stanie zobaczyć pełną definicję funkcji constexpr przed takimi wywołaniami funkcji (aby mógł sam przeprowadzić ocenę) W tym przypadku deklaracja forward nie wystarczy, nawet jeśli rzeczywista definicja funkcji pojawi się później w tej samej jednostce kompilacji.

Oznacza to, że funkcja constexpr jest wywoływana wielokrotnie). pliki muszą mieć definicję zawarta w każdej jednostce tłumaczenia — co normalnie byłoby naruszeniem reguły jednej definicji. Aby uniknąć takich problemów, funkcje constexpr są domyślnie wbudowane, co czyni je zwolnionymi z reguły jednej definicji.

W rezultacie funkcje constexpr są często definiowane w plikach nagłówkowych, więc można je #włączyć do dowolnego pliku .cpp wymagającego pełnej definicji.

Dla constexpr wywołania funkcji, które są oceniane tylko w czasie wykonywania, deklaracja forward jest wystarczająca, aby zadowolić kompilator. Oznacza to, że możesz użyć deklaracji forward do wywołania funkcji constexpr zdefiniowanej w innej jednostce tłumaczenia, ale tylko wtedy, gdy wywołasz ją w kontekście, który nie wymaga oceny w czasie kompilacji.

#include <iostream>

constexpr int foo(int);

constexpr int goo(int c)
{
	return foo(c);   // note that foo is not defined yet
}

constexpr int foo(int b) // okay because foo is still defined before any calls to goo
{
	return b;
}

int main()
{
	 constexpr int a{ goo(5) }; // this is the outermost invocation

	return 0;
}

Podsumowanie

Oznaczenie funkcji jako constexpr oznacza, że może być używana w stałej wyrażenie. Nie oznacza to, że „będzie oceniane w czasie kompilacji”.

Wyrażenie stałe (które może zawierać wywołania funkcji constexpr) jest wymagane tylko do oceny w czasie kompilacji w kontekstach, w których wymagane jest wyrażenie stałe.

W kontekstach, które nie wymagają wyrażenia stałego, kompilator może wybrać, czy obliczyć stałe wyrażenie (które może zawierać wywołania funkcji constexpr) w czasie kompilacji czy w czasie wykonywania.

Środowisko wykonawcze. (nie stałe) wyrażenie (które może zawierać wywołania funkcji constexpr lub wywołania funkcji inne niż constexpr) zostanie obliczone w czasie wykonywania.

Kolejny przykład

Przeprowadźmy jeszcze raz badanie, aby sprawdzić, w jaki sposób funkcja constexpr jest wymagana lub prawdopodobnie będzie dalej oceniana:

#include <iostream>

constexpr int greater(int x, int y)
{
    return (x > y ? x : y);
}

int main()
{
    constexpr int g { greater(5, 6) };              // case 1: always evaluated at compile-time
    std::cout << g << " is greater!\n";

    std::cout << greater(5, 6) << " is greater!\n"; // case 2: may be evaluated at either runtime or compile-time

    int x{ 5 }; // not constexpr but value is known at compile-time
    std::cout << greater(x, 6) << " is greater!\n"; // case 3: likely evaluated at runtime

    std::cin >> x;
    std::cout << greater(x, 6) << " is greater!\n"; // case 4: always evaluated at runtime

    return 0;
}

W przypadku 1 wywołujemy greater() w kontekście wymagającym stałego wyrażenia. Zatem greater() musi zostać obliczone w czasie kompilacji.

W przypadku 2 funkcja greater() jest wywoływana w kontekście, który nie wymaga wyrażenia stałego, ponieważ instrukcje wyjściowe muszą zostać wykonane w czasie wykonywania. Jednakże, ponieważ argumenty są wyrażeniami stałymi, funkcja może zostać oceniona w czasie kompilacji, zatem kompilator może wybrać, czy wywołanie greater() zostanie obliczony w czasie kompilacji lub w czasie wykonywania.

W przypadku 3 wywołujemy greater() z jednym argumentem, który nie jest wyrażeniem stałym. Będzie to więc zazwyczaj wykonywane w czasie wykonywania.

Jednakże ten argument ma wartość znaną w czasie kompilacji. Zgodnie z regułą as-if kompilator może zdecydować się na potraktowanie oceny x jako wyrażenia stałego i oszacowanie tego wywołania do greater() w czasie kompilacji. Ale bardziej prawdopodobne, że oceni to w czasie wykonywania.

W przypadku 4 wartość argumentu x nie może być znana w czasie kompilacji, więc to wywołanie greater() będzie zawsze oceniane w czasie wykonywania.

Pamiętaj, że ustawienie poziomu optymalizacji kompilatora może mieć wpływ na to, czy decyduje się ocenić funkcję w czasie kompilacji lub w czasie wykonywania. Oznacza to również, że Twój kompilator może dokonywać różnych wyborów w przypadku kompilacji debugowania i wydań (ponieważ kompilacje debugowania zazwyczaj mają wyłączone optymalizacje).

Na przykład zarówno gcc, jak i Clang nie będą oceniać w czasie kompilacji funkcji constexpr wywoływanej tam, gdzie stałe wyrażenie nie jest wymagane, chyba że kompilator otrzyma polecenie optymalizacji kodu (np. używając opcji -O2 kompilatora).