Wie man das Problem "Lesen der Nicht-Constexpr-Variablen 'a' ist in einem konstanten Ausdruck nicht erlaubt" mit boost.hana löst

Ich verwende c ++ 17 mit Boost.hana, um einige Metaprogrammierprogramme zu schreiben. Ein Problem, das mir aufgefallen ist, ist, welche Art von Ausdruck in einem constexpr-Kontext wie static_assert verwendet werden kann. Hier ist ein Beispiel:

#include <boost/hana.hpp>

using namespace boost::hana::literals;

template <typename T>
class X {
public:
    T data;

    constexpr explicit X(T x) : data(x) {}

    constexpr T getData() {
        return data;
    }
};


int main() {
    {   // test1
        auto x1 = X(1_c);
        static_assert(x1.data == 1_c);
        static_assert(x1.getData() == 1_c);
    }
    {   //test2.1
        auto x2 = X(boost::hana::make_tuple(1_c, 2_c));
        static_assert(x2.data[0_c] == 1_c);

        // static_assert(x2.getData()[0_c] == 1_c); // read of non-constexpr variable 'x2' is not allowed in a constant expression
    }
    {   //test2.2
        auto x2 = X(boost::hana::make_tuple(1_c, 2_c));
        auto data = x2.getData();
        static_assert(data[0_c] == 1_c);
    }
}

Zuerst schreibe ich eine Klasse X mit einem Felddaten und einem Accessor getData () . In der main () ‚s test1 Teil, x1.data und x1.getData () verhalten sich gleich wie ich erwartet hatte. Aber im Test2- Teil static_assert(x2.data[0_c] == 1_c)verhält sich das Ändern des Arguments in ein Boost :: Hanas-Tupel immer noch gut, static_assert(x2.getData()[0_c] == 1_c)schlägt jedoch bei der Kompilierung fehl, wobei der Fehler ' Lesen der Nicht-Constexpr-Variablen' x2 'in einem konstanten Ausdruck nicht zulässig ist '. Was weired ist , wenn ich aufgeteilt x2.getData()[0_c]in auto data = x2.getData();und static_assert(data[0_c] == 1_c);kompiliert es wieder gut. Ich würde erwarten, dass sie sich gleich verhalten. Kann jemand helfen zu erklären, warum x2.getData()[0_c]in static_assert in diesem Beispiel nicht verwendet werden kann?

Zum Reproduzieren: clang ++ 8.0 -I / path / to / hana-1.5.0 / include -std = c ++ 17 Test.cpp

Das Problem ist, dass boost::hana::tuplees keinen Kopierkonstruktor gibt.

Es hat einen Konstruktor , der wie ein Kopierkonstruktor aussieht :

template <typename ...dummy, typename = typename std::enable_if<
    detail::fast_and<BOOST_HANA_TT_IS_CONSTRUCTIBLE(Xn, Xn const&, dummy...)...>::value
>::type>
constexpr tuple(tuple const& other)
    : tuple(detail::from_index_sequence_t{},
            std::make_index_sequence<sizeof...(Xn)>{},
            other.storage_)
{ }

Da es sich jedoch um eine Vorlage handelt, handelt es sich nicht um einen Kopierkonstruktor .

Da boost::hana::tuplekeine Kopie Konstruktor wird eine implizit deklarierte und als ausgefallen definiert (es nicht unterdrückt wird , da boost::hana::tuplenicht hat keine Kopie oder verschieben Bauer oder Zuweisungsoperatoren, weil, Sie ahnen es, sie können nicht Vorlagen sein).

Hier sehen wir Implementierungsdivergenzen , die sich im Verhalten des folgenden Programms zeigen:

struct A {
    struct B {} b;
    constexpr A() {};
    // constexpr A(A const& a) : b{a.b} {}    // #1
};
int main() {
    auto a = A{};
    constexpr int i = (A{a}, 0);
}

gcc akzeptiert, während Clang und MSVC ablehnen, aber akzeptieren, wenn die Zeile nicht kommentiert #1ist. Das heißt, die Compiler sind sich nicht einig darüber, ob der implizit definierte Kopierkonstruktor einer nicht (direkt) leeren Klasse im Kontext einer konstanten Auswertung verwendet werden darf.

Gemäß der Definition des implizit definierten Kopierkonstruktors gibt es keine Möglichkeit, dass sich # 1 von der von constexpr A(A const&) = default;gcc unterscheidet . Beachten Sie auch, dass, wenn wir B einen benutzerdefinierten constexpr-Kopierkonstruktor geben, Clang und MSVC erneut akzeptieren, das Problem anscheinend darin besteht, dass diese Compiler die constexpr-Kopierkonstruktierbarkeit rekursiv leerer implizit kopierbarer Klassen nicht verfolgen können. Fehler für MSVC und Clang behoben ( behoben für Clang 11).

Beachten Sie, dass die Verwendung von operator[]ein roter Hering ist; Die Frage ist, ob die Compiler den Aufruf getData()(welche Kopierkonstrukte T) in einem Kontext mit konstanter Auswertung zulassen, wie z static_assert.

Offensichtlich wäre die ideale Lösung für Boost.Hana, so zu korrigieren boost::hana::tuple, dass es tatsächliche Kopier- / Verschiebungskonstruktoren und Kopier- / Verschiebungszuweisungsoperatoren hat. (Dies würde Ihren Anwendungsfall beheben, da der Code vom Benutzer bereitgestellte Kopierkonstruktoren aufruft, die im Kontext einer konstanten Auswertung zulässig sind.) Um dieses Problem getData()zu umgehen , können Sie Hacking in Betracht ziehen , um den Fall eines nicht zustandsbehafteten Falls zu erkennen T:

constexpr T getData() {
    if (data == T{})
        return T{};
    else
        return data;
}

Das Problem liegt darin, dass Sie versuchen, einen Laufzeitwert abzurufen und bei der Kompilierung zu testen.

Was Sie tun können, ist, den Ausdruck zur Kompilierungszeit durch a zu zwingen decltypeund es wird wie ein Zauber funktionieren :).

static_assert(decltype(x2.getData()[0_c]){} == 1_c);

#include <boost/hana.hpp>

using namespace boost::hana::literals;

template <typename T>
class X {
public:
    T data;

   constexpr explicit X(T x) : data(x) {}

   constexpr T getData() {
        return data;
    }
};


int main() {
    {   // test1
        auto x1 = X(1_c);
        static_assert(x1.data == 1_c);
        static_assert(x1.getData() == 1_c);
    }
    {   //test2
        auto x2 = X(boost::hana::make_tuple(1_c, 2_c));
        static_assert(x2.data[0_c] == 1_c);

         static_assert(decltype(x2.getData()[0_c]){} == 1_c);

        auto data = x2.getData();
        static_assert(data[0_c] == 1_c);
    }
}

Jetzt wird der Ausdruck zur Kompilierungszeit ausgewertet, sodass der Typ zur Kompilierungszeit bekannt ist. Da er auch zur Rechenzeit konstruierbar ist, kann er in einem static_assert verwendet werden

Zuallererst fehlt Ihnen das const-Qualifikationsmerkmal in der getData()Methode, also sollte es sein:

constexpr T getData() const

Zumindest aus Standardsicht wird keine Variable als constexpr befördert, wenn sie nicht als constexpr markiert ist.

Beachten Sie, dass dies nicht erforderlich x1ist X, da es sich 1_cum einen Typ handelt, der auf hana :: Integral_constant spezialisiert ist, da das Ergebnis ein Typ ohne benutzerdefinierten Kopierkonstruktor ist, der intern keine Daten enthält, sodass eine Kopieroperation getData()in tatsächlich ein No-Op ist , also Ausdruck: static_assert(x1.getData() == 1_c); ist in Ordnung, da keine tatsächliche Kopie erstellt wird (und auch kein Zugriff auf einen nicht konstanten thisZeiger von x1erforderlich ist).

Dies ist sehr unterschiedlich für Ihren Container, hana::tupleder eine sachliche Kopienkonstruktion hana::tupleaus Daten enthältx2.data Feld enthält. Dies erfordert einen sachlichen Zugriff auf Ihren thisZeiger - was im Fall von nicht erforderlich x1war und auch keine constexpr-Variable war.

Dies bedeutet , dass Sie äußern Ihre Absicht falsch mit beiden x1und x2, und es ist notwendig, zumindest für x2diese Variablen als constexpr zu markieren. Beachten Sie auch, dass die Verwendung von leerem Tupel, einer grundsätzlich leeren Spezialisierung (keine benutzerdefinierten Kopierkonstruktoren) im Allgemeinen hana::tuple, nahtlos funktioniert (Abschnitt test3):

#include <boost/hana.hpp>

using namespace boost::hana::literals;

template <typename T>
class X {
public:
    T data;

    constexpr explicit X(T x) : data(x) {}

    constexpr T getData() const {
        return data;
    }
};

template<typename V>
constexpr auto make_X(V value)
{
    return value;
}

int main() {
    {   // test1
        auto x1 = X(1_c);
        static_assert(x1.data == 1_c);
        static_assert(x1.getData() == 1_c);
    }
    {   //test2
        constexpr auto x2 = X(boost::hana::make_tuple(1_c, 2_c));
        static_assert(x2.data[0_c] == 1_c);

        static_assert(x2.getData()[0_c] == 1_c); // read of non-constexpr variable 'x2' is not allowed in a constant expression

        auto data = x2.getData();
        static_assert(data[0_c] == 1_c);
    }
    {   //test3
        auto x3 = X(boost::hana::make_tuple());
        static_assert(x3.data == boost::hana::make_tuple());

        static_assert(x3.getData() == boost::hana::make_tuple());
    }
}