It’s ugly, and probably not the best way to sort in a constant expression (because of the required instantiation depth).. but voilà, a merge sort: Helper type, returnable array type with constexpr element access: #include <cstddef> #include <iterator> #include <type_traits> template<class T, std::size_t N> struct c_array { T arr[N]; constexpr T const& operator[](std::size_t p) const … Read more
The One Definition rule tells us that we can not have more than one definition of an odr-used variable in a program. So if a variable is odr-used then you need to define it but you can not define it the header file since it may be included more than once with the whole program. … Read more
The program is ill-formed and requires no diagnostic according to the C++11 draft standard section 7.1.5 The constexpr specifier paragraph 5 which says: For a constexpr function, if no function argument values exist such that the function invocation substitution would produce a constant expression (5.19), the program is ill-formed; no diagnostic required. and provides the … Read more
In C++20 you can just replace constexpr by consteval to enforce a function to be always evaluated at compile time. Example: int rt_function(int v){ return v; } constexpr int rt_ct_function(int v){ return v; } consteval int ct_function(int v){ return v; } int main(){ constexpr int ct_value = 1; // compile value int rt_value = 2; … Read more
As T.C. demonstrated with some links in a comment, the standard is not quite clear on this; a similar problem arises with trailing return types using decltype(memberfunction()). The central problem is that class members are generally not considered to be declared until after the class in which they’re declared is complete. Thus, regardless of the … Read more
The standard committee seems to intend on initializer_list being a literal type. However, it doesn’t look like it’s an explicit requirement, and seems to be a bug in the standard. From § 3.9.10.5: A type is a literal type if it is: – a class type (Clause 9) that has all of the following properties: … Read more
From memory, member function bodies are evaluated only once the class has been completely defined. static constexpr int bah = static_n_items(); forms part of the class definition, but it’s referring to a (static) member function, which cannot yet be defined. Solution: defer constant expressions to a base class and derive from it. e.g.: struct Item_id_base … Read more
clang is correct, note the HEAD revision of gcc accepts also accepts this code. This is a well-formed constexpr function, as long as there is value for the argument(s) that allows the function to be evaluated as a core constant expression. In your case 1 is such a value. This is covered in the draft … Read more
The issue is that in a variable declaration, constexpr always applies the const-ness to the object declared; const on the other hand can apply to a different type, depending on the placement. Thus constexpr const int i = 3; constexpr int i = 3; are equivalent; constexpr char* p = nullptr; constexpr char* const p … Read more
constexpr variable is guaranteed to have a value available at compile time. whereas static const members or const variable could either mean a compile time value or a runtime value. Typing constexpr express your intent of a compile time value in a much more explicit way than const. One more thing, in C++17, constexpr static … Read more