constexpr

std::is_constant_evaluated behavior

放肆的年华 提交于 2019-12-04 22:51:18
GCC9 already implements std::is_constant_evaluated . I played a little bit with it, and I realized it is somewhat tricky. Here’s my test: constexpr int Fn1() { if constexpr (std::is_constant_evaluated()) return 0; else return 1; } constexpr int Fn2() { if (std::is_constant_evaluated()) return 0; else return 1; } int main() { constexpr int test1 = Fn1(); // Evaluates to 0 int test2 = Fn1(); // Evaluates to 0 int const test3 = Fn1(); // Evaluates to 0 constexpr int test4 = Fn2(); // Evaluates to 0 int test5 = Fn2(); // Evaluates to 1 int const test6 = Fn2(); // Evaluates to 0 } According to

Why must non-integral static data members initialized in the class be constexpr?

。_饼干妹妹 提交于 2019-12-04 22:33:03
Static integral data members initialized in the class definition may be declared const or constexpr , but non-integral static data members initialized in the class definition must be constexpr : class MyClass { static const int w = 5; // okay static constexpr int x = 5; // okay static const float y = 1.5; // error! static constexpr float z = 1.5; // okay }; Does anybody know why the declaration for y is not permitted? The part of the Standard making it illegal is 9.4.2/3, but why is it illegal? Prior to C++11, you could not initialize static members of non-integral/enumeration types in the

Why must a string be constructed at run-time? [duplicate]

情到浓时终转凉″ 提交于 2019-12-04 22:22:51
This question already has an answer here: Is it possible to use std::string in a constexpr? 4 answers Can C-Strings or std::string s be created as constexpr or must they be created at run-time? With gcc 4.9.2 I can do this: constexpr const char foo[] = "blee"; (Sadly the November 2013 Customer Technology Preview does not allow Visual Studio to support this: https://stackoverflow.com/a/29255013/2642059 ) But even with gcc 4.9.2 I cannot do this: constexpr const std::string foo = "blee"; I get the error: error: the type 'const string {aka const std::basic_string<char>}' of constexpr variable

Using an int as a template parameter that is not known until run-time

江枫思渺然 提交于 2019-12-04 21:35:15
问题 I am trying to use an integer as a template parameter for a class. Here is a sample of the code: template< int array_qty > class sample_class { public: std::array< std::string, array_qty > sample_array; } If I do so something like this, it works: sample_class< 10 > sample_class_instance; However, let's say that I do not know the value of array_qty (the template parameter) when compiling, and will only know it during run-time. In this case, I would essentially be passing an int variable as the

`constexpr` variable “used in its own initializer”: Clang vs. GCC

纵然是瞬间 提交于 2019-12-04 20:36:58
问题 This question seems related to an existing one, but I do not understand the "portable workaround" provided in the answer there (involving const auto this_ = this; ) and moreover I think the following example is easier to follow. I am playing with the following snippet of C++17 code (live demo): #include <iostream> struct Test { const char* name_{nullptr}; const Test* src_{nullptr}; constexpr Test(const char* name) noexcept : name_{name} {} constexpr Test(const Test& src) noexcept : src_{&src}

Why should I prefer static constexpr int in a class over enum for class-level integral constants?

回眸只為那壹抹淺笑 提交于 2019-12-04 18:10:47
问题 C++17 Update: static constexpr variables are implicitly inline so there's no external definition necessary. Original question: Let's say I have a list of constants such as struct Cls { static constexpr int N = 32; static constexpr int M = 64; }; This of course suggests that I add definitions for these to avoid ODR-usage issues that may occur so I need: constexpr int Cls::N; constexpr int Cls::M; Why should I prefer this over struct Cls { enum : int { N = 32, M = 64 }; }; Which saves me of the

Confusion about constant expressions

最后都变了- 提交于 2019-12-04 17:31:48
问题 This is some kind of follow-up for this topic and deals about a little part of it. As with the previous topic, let's consider that our compiler has constexpr functions for std::initializer_list and std::array . Now, let's go straight to the point. This works: #include <array> #include <initializer_list> int main() { constexpr std::array<int, 3> a = {{ 1, 2, 3 }}; constexpr int a0 = a[0]; constexpr int a1 = a[1]; constexpr int a2 = a[2]; constexpr std::initializer_list<int> b = { a0, a1, a2 };

C++ constexpr function in return statement

非 Y 不嫁゛ 提交于 2019-12-04 16:45:47
问题 Why is a constexpr function no evaluated at compile time but in runtime in the return statement of main function? It tried template<int x> constexpr int fac() { return fac<x - 1>() * x; } template<> constexpr int fac<1>() { return 1; } int main() { const int x = fac<3>(); return x; } and the result is main: push rbp mov rbp, rsp mov DWORD PTR [rbp-4], 6 mov eax, 6 pop rbp ret with gcc 8.2. But when I call the function in the return statement template<int x> constexpr int fac() { return fac<x

Can virtual functions be constexpr?

泪湿孤枕 提交于 2019-12-04 16:29:56
问题 Can virtual functions like X::f() in the following code struct X { constexpr virtual int f() const { return 0; } }; be constexpr ? 回答1: This answer is no longer correct as of C++20. No. From [dcl.constexpr]/3 (7.1.5, "The constexpr specifier"): The definition of a constexpr function shall satisfy the following requirements: — it shall not be virtual 回答2: Up through C++17, virtual functions could not be declared constexpr . The general reason being that, in constexpr code, everything happen

Is taking the address of a local variable a constant expression in C++11?

我是研究僧i 提交于 2019-12-04 16:11:07
问题 The following C++11 program: int x = 42; void f() { int y = 43; static_assert(&x < &y, "foo"); } int main() { f(); } Doesn't compile with gcc 4.7 as it complains: error: ‘&y’ is not a constant expression This would agree with my intuition. The address of y potentially changes with each invocation of f , so of course it cannot be calculated during translation. However none of the bullet points in 5.19 [expr.const] seem to preclude it from being a constant expression. The only two contenders I