How would one properly do a `static_assert` within a `constexpr` function?  For example:

    constexpr int do_something(int x)
    {
      static_assert(x &gt; 0, &quot;x must be &gt; 0&quot;);
      return x + 5;
    }

This is not valid C++11 code, because a constexpr function must only contain a return statement.  I don&#39;t think that the standard has an exception to this, although, the GCC 4.7 does not let me compile this code.

C++11 - static_assert within constexpr function?

Is there a difference between declaring floating point constant as a `static constexpr` variable and a function as in example below, or is it just a matter of style?

    class MY_PI
    {
    public:
        static constexpr float MY_PI_VAR = 3.14f;
        static constexpr float MY_PI_FUN() { return 3.14f; }
    }

static constexpr variable vs function

    #include &lt;iostream&gt;
    #include &lt;type_traits&gt;
    
    int main(){
    	
    	//creating an integral constant with constexpr
    	constexpr unsigned int speed_of_light{299792458};
    	
    	//creating an integral constant with std::integral_constant
    	typedef std::integral_constant&lt;unsigned int, 299792458&gt; speed_of_light_2;
    	
    	//using them
    	std::cout &lt;&lt; speed_of_light/2 &lt;&lt; &#39;\n&#39;;
    	std::cout &lt;&lt; speed_of_light_2::value/2 &lt;&lt; &#39;\n&#39;;
    
    }

What&#39;s special about `std::integral_constant` that I would choose to use it over `constexpr`?  
Their behaviour and use cases look identical to me.  I&#39;m trying to think of some kind of template scenario, where constexpr may not suffice. 

When would I use std::integral_constant over constexpr?

[P0292R1 constexpr if][1] has been [included][2], on track for C++17. It seems useful (and can replace use of SFINAE), but a comment regarding `static_assert` being *ill-formed, no diagnostic required* in the false branch scares me:

    Disarming static_assert declarations in the non-taken branch of a
    constexpr if is not proposed.

    void f() {
      if constexpr (false)
        static_assert(false);   // ill-formed
    }
    
    template&lt;class T&gt;
    void g() {
      if constexpr (false)
        static_assert(false);   // ill-formed; no 
                   // diagnostic required for template definition
    }

I take it that it&#39;s completely forbidden to use `static_assert` inside constexpr if (at least the false / non-taken branch, but that in practice means it&#39;s not a safe or useful thing to do).

How does this come about from the standard text? I find no mentioning of `static_assert` in the proposal wording, and C++14 constexpr functions do allow `static_assert` (details at cppreference: [constexpr][3]).

Is it hiding in this new sentence (after 6.4.1) ? : 

&gt;    When a constexpr if statement appears in a templated entity, 
&gt;    during an instantiation of the enclosing template or generic lambda, 
&gt;    a discarded statement is not instantiated.

From there on, I assume that it is also forbidden, no diagnostic required, to call other constexpr (template) functions which *somewhere* down the call graph may call `static_assert`. 

**Bottom line:** 

If my understanding is correct, doesn&#39;t that put a quite hard limit on the safety and usefulness of `constexpr if` as we would have to know (from documentation or code inspection) about any use of `static_assert`? Are my worries misplaced?


  [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0292r1.html
  [2]: https://herbsutter.com/2016/06/30/trip-report-summer-iso-c-standards-meeting-oulu/
  [3]: http://en.cppreference.com/w/cpp/language/constexpr

**Update:**

This code compiles without warning (clang head 3.9.0) but is to my understanding *ill-formed*, no diagnostic required. Valid or not?

    template&lt; typename T&gt;
    constexpr void other_library_foo(){
        static_assert(std::is_same&lt;T,int&gt;::value);
    }
    
    template&lt;class T&gt;
    void g() {
      if constexpr (false)
        other_library_foo&lt;T&gt;(); 
    }
    
    int main(){
        g&lt;float&gt;();
        g&lt;int&gt;();
    }

constexpr if and static_assert

As you probably know, C++11 introduces the `constexpr` keyword.

&gt; C++11 introduced the keyword constexpr, which allows the user to
&gt; guarantee that a function or object constructor is a compile-time
&gt; constant.
&gt; [...]
&gt; This allows the compiler to understand, and verify, that [function name] is a
&gt; compile-time constant.

My question is why are there such strict restrictions on form of the functions that can be declared. I understand desire to guarantee that function is pure, but consider this:

&gt; The use of constexpr on a function imposes some limitations on what
&gt; that function can do. First, the function must have a non-void return
&gt; type. Second, the function body cannot declare variables or define new
&gt; types. Third, the body may only contain declarations, null statements
&gt; and a single return statement. There must exist argument values such
&gt; that, after argument substitution, the expression in the return
&gt; statement produces a constant expression.

That means that this pure function is illegal:

    constexpr int maybeInCppC1Y(int a, int b)
    {
    	if (a&gt;0)
    		return a+b;
    	else
    		return a-b;
      //can be written as  	return  (a&gt;0) ? (a+b):(a-b); but that isnt the point
    }
Also you cant define local variables... :( 
So I&#39;m wondering is this a design decision, or do compilers suck when it comes to proving function a is pure?

Why is C++11 constexpr so restrictive?

I am compiling the following simple program with `g++-4.6.1 --std=c++0x`:

    #include &lt;algorithm&gt;

    struct S
    {
        static constexpr int X = 10;
    };

    int main()
    {
        return std::min(S::X, 0);
    };

I get the following linker error:

    /tmp/ccBj7UBt.o: In function `main&#39;:
    scratch.cpp:(.text+0x17): undefined reference to `S::X&#39;
    collect2: ld returned 1 exit status

I realize that inline-defined static members do not have symbols defined, but I was under the (probably flawed) impression that using `constexpr` told the compiler to always treat the symbol as an expression; so, the compiler would know that it is not legal to pass a reference to the symbol `S::X` (for the same reason you can&#39;t take a reference to the literal `10`).

However if S is declared as namespace, i.e. &quot;namespace S&quot; instead of &quot;struct S&quot;, everything links fine.

Is this a `g++` bug or do I still have to use a trick to workaround this annoyance?

C++ Linker Error With Class static constexpr

C++11 allows functions declared with the `constexpr` specifier to be used in constant expressions such as template arguments. There are stringent requirements about what is allowed to be `constexpr`; essentially such a function encapsulates only one subexpression and nothing else. (Edit: this is relaxed in C++14 but the question stands.)

Why require the keyword at all? **What is gained?**

It does help in revealing the intent of an interface, but it [doesn&#39;t][1] validate that intent, by guaranteeing that a function is usable in constant expressions. After writing a `constexpr` function, a programmer must still:

1. Write a test case or otherwise ensure it&#39;s actually used in a constant expression.
2. Document what parameter values are valid in a constant expression context.

Contrary to revealing intent, decorating functions with `constexpr` may add a false sense of security since tangential syntactic constraints are checked while ignoring the central semantic constraint.

---

**In short:** Would there be any undesirable effect on the language if `constexpr` in function declarations were merely optional? Or would there be any effect at all on any valid program?

  [1]: https://stackoverflow.com/q/13295089/153285

Why do we need to mark functions as constexpr?

Related: https://stackoverflow.com/questions/7779013/probrem-with-constexpr-how-to-resolve-it

I feel like constexpr is limited in usefulness in C++11 because of the inability to define two functions that would otherwise have the same signature, but have one be constexpr and the other not constexpr. In other words, it would be very helpful if I could have, for example, a constexpr std::string constructor that takes constexpr arguments only, and a non-constexpr std::string constructor for non-constexpr arguments. Another example would be a theoretically complicated function that could be made more efficient by using state. You can&#39;t easily do that with a constexpr function, so you are left with two choices: have a constexpr function that is very slow if you pass in non-constexpr arguments, or give up on constexpr entirely (or write two separate functions, but you may not know which version to call).

My question, therefore, is this:

Is it possible for a standard-compliant C++11 implementation to allow function overloading based on the arguments being constexpr, or would this require updating the standard? If it is not allowed, was it intentionally not allowed?

--------------------

@NicolBolas: Say I have a function that maps an `enum` to a `std::string`. The most straight-forward way to do this, assuming my `enum` goes from `0` to `n - 1`, is to create an array of size `n` filled with the result.

I could create a `static constexpr char const * []` and construct a `std::string` on return (paying the cost of creating a `std::string` object every time I call the function), or I can create a `static std::string const []` and return the value I look up, paying the cost of all of the `std::string` constructors the first time I call the function. It seems like a better solution would be to create the `std::string` in memory at compile time (similar to what is done now with `char const *`), but the only way to do this would be to alert the constructor that it has `constexpr` arguments.

For a an example other than a `std::string` constructor, I think it&#39;s pretty straight-forward to find an example where, if you could ignore the requirements of `constexpr` (and thus create a non-`constexpr` function), you could create a more efficient function. Consider this thread: https://stackoverflow.com/questions/7065200/constexpr-question-why-do-these-two-different-programs-run-in-such-a-different

If I call `fib` with a `constexpr` argument, I can&#39;t beat do better than the compiler optimizing away the function call entirely. But if I call `fib` with a non-`constexpr` argument, I may want to have it call my own version that implements things like memoization (which would require state) so I get run time similar to what would have been my compile time had I passed a `constexpr` argument.

constexpr overloading

I was researching what is allowed in a [core constant expression*](http://en.cppreference.com/w/cpp/language/constant_expression), which is covered in section `5.19` *Constant expressions* paragraph *2* of the [draft C++ standard](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3485.pdf) which says:

&gt;A conditional-expression is a core constant expression unless it involves one of the following as a potentially evaluated subexpression (3.2), but subexpressions of logical AND (5.14), logical OR (5.15), and conditional (5.16) operations that are not evaluated are not considered [ Note: An overloaded operator invokes a function.—end note ]:

and lists out the exclusions in the bullets that follows and includes (*emphasis mine*):

&gt;— **an operation that would have undefined behavior** [ Note: including, for example, signed integer overflow (Clause 5), certain pointer arithmetic (5.7), division by zero (5.6), or certain shift operations (5.8) —end note ];

*Huh*? Why do *constant expressions* need this clause to cover [undefined behavior](http://en.wikipedia.org/wiki/Undefined_behavior)? Is there something special about *constant expressions* that requires *undefined behavior* to have a special carve out in the exclusions?

Does having this clause give us any advantages or tools we would not have without it?

For reference, this looks like the last revision of the proposal for [Generalized Constant Expressions](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf).


Why do constant expressions have an exclusion for undefined behavior?

This code is giving me **incomplete type** error.
What is the problem? Isn&#39;t allowed for a class to have **static member instances** of itself?
Is there a way to achieve the same result?

    struct Size
    {
        const unsigned int width;
        const unsigned int height;
    
        static constexpr Size big = { 480, 240 };
    
        static constexpr Size small = { 210, 170 };
    
    private:
    
        Size( ) = default;
    };

Can&#39;t a class have static constexpr member instances of itself?

I&#39;ve been learning about C++ `constexpr` functions, and I implemented a `constexpr` recursive function to find the nth fibonacci number.

```cpp
#include &lt;iostream&gt;
#include &lt;fstream&gt;
#include &lt;cmath&gt;
#include &lt;algorithm&gt;
#include &lt;vector&gt;

constexpr long long fibonacci(int num) {
	if (num &lt;= 2) return 1;
	return fibonacci(num - 1) + fibonacci(num - 2);
}

int main() {
	auto start = clock();
	long long num = fibonacci(70);
	auto duration = (clock() - start) / (CLOCKS_PER_SEC / 1000.);
	std::cout &lt;&lt; num &lt;&lt; &quot;\n&quot; &lt;&lt; duration &lt;&lt; std::endl;
}
```
If I remove the `constexpr` identifier from the `fibonacci()` function, then `fibonacci(70)` takes a *very long* time to evaluate (more than 5 minutes). When I keep it as-is, however, the program still compiles within 3 seconds and prints out the correct result in less than `0.1` milliseconds.

I&#39;ve learned that `constexpr` functions are evaluated **at compile time**, so this would mean that `fibonacci(70)` is calculated by the compiler in less than 3 seconds! However, it doesn&#39;t seem quite right that the C++ compiler would have such better calculation performance than C++ code.

My question is, does the C++ compiler actually evaluate the function between the time I press the &quot;Build&quot; button and the time the compilation finishes? Or am I misunderstanding the keyword `constexpr`?

EDIT: This program was compiled with `g++ 7.5.0` with `--std=c++17`.

How does the C++ compiler evaluate recursive constexpr functions so quickly?

If I have a variable inside a function (say, a large array), does it make sense to declare it both `static` and `constexpr`? `constexpr` guarantees that the array is created at compile time, so would the `static` be useless?

	void f() {
		static constexpr int x [] = {
			// a few thousand elements
		};
		// do something with the array
	}

Is the `static` actually doing anything there in terms of generated code or semantics?

Does static constexpr variable inside a function make sense?

*Using C++11, Ubuntu 14.04, GCC default toolchain*.

This code fails:

    constexpr std::string constString = &quot;constString&quot;;

&gt; error: the type ‘const string {aka const std::basic_string&lt;char&gt;}’ of
&gt; constexpr variable ‘constString’ is not literal... because...
&gt; ‘std::basic_string&lt;char&gt;’ has a non-trivial destructor

Is it possible to use `std::string` in a`constexpr`? (apparently not...) If so, how? Is there an alternative way to use a character string in a `constexpr`?


Is it possible to use std::string in a constexpr?

I want to have a `static const` `char` array in my class. GCC complained and told me I should use `constexpr`, although now it&#39;s telling me it&#39;s an undefined reference. If I make the array a non-member then it compiles. What is going on?

    // .hpp
    struct foo {
      void bar();
      static constexpr char baz[] = &quot;quz&quot;;
    };

    // .cpp
    void foo::bar() {
      std::string str(baz); // undefined reference to baz
    }



Undefined reference to static constexpr char[]

What&#39;s the difference between `constexpr` and `const`?

- When can I use only one of them?  
- When can I use both and how should I choose one?

What&#39;s the difference between constexpr and const?

Consider the following inlined function :

    // Inline specifier version
    #include&lt;iostream&gt;
    #include&lt;cstdlib&gt;
    
    inline int f(const int x);
    
    inline int f(const int x)
    {
        return 2*x;
    }
    
    int main(int argc, char* argv[])
    {
        return f(std::atoi(argv[1]));
    }

and the constexpr equivalent version :

    // Constexpr specifier version
    #include&lt;iostream&gt;
    #include&lt;cstdlib&gt;
    
    constexpr int f(const int x);
    
    constexpr int f(const int x)
    {
        return 2*x;
    }
    
    int main(int argc, char* argv[])
    {
        return f(std::atoi(argv[1]));
    }

My question is : does the `constexpr` specifier imply the `inline` specifier in the sense that if a non-constant argument is passed to a `constexpr` function, the compiler will try to `inline` the function as if the `inline` specifier was put in its declaration ?

Does the C++11 standard guarantee that ?




Does constexpr imply inline?

Where should I prefer using *macros* and where should I prefer *constexpr*?
Aren&#39;t they basically the same?

    #define MAX_HEIGHT 720

vs

    constexpr unsigned int max_height = 720;

Constexpr vs macros

I&#39;m trying to compute the length of a string literal at compile time. To do so I&#39;m using following code:

    #include &lt;cstdio&gt;
    
    int constexpr length(const char* str)
    {
        return *str ? 1 + length(str + 1) : 0;
    }
    
    int main()
    {
        printf(&quot;%d %d&quot;, length(&quot;abcd&quot;), length(&quot;abcdefgh&quot;));
    }

Everything works as expected, the program prints 4 and 8. The assembly code generated by clang shows that the results are computed at compile time:

    0x100000f5e:  leaq   0x35(%rip), %rdi          ; &quot;%d %d&quot;
    0x100000f65:  movl   $0x4, %esi
    0x100000f6a:  movl   $0x8, %edx
    0x100000f6f:  xorl   %eax, %eax
    0x100000f71:  callq  0x100000f7a               ; symbol stub for: printf

**My question: is it guaranteed by the standard that `length` function will be evaluated compile time?** 

If this is true the door for compile time string literals computations just opened for me... for example I can compute hashes at compile time and many more... 

Computing length of a C string at compile time. Is this really a constexpr?

At the very end of Scott Schurr&#39;s talk [&quot;Introducing `constexpr`&quot; at CppCon][1], he asks &quot;Is there a way to poison a function&quot;? He then explains that this can be done (albeit in a non-standard way) by:

1. Putting a `throw` in a `constexpr` function
2. Declaring an unresolved `extern const char*`
3. Referencing the unresolved `extern` in the `throw`

I sense that I&#39;m a bit out of my depth here, but I&#39;m curious:

- What does it mean to &quot;poison a function&quot;?
- What is the significance/usefulness of the technique he outlines?

  [1]: https://youtu.be/fZjYCQ8dzTc?t=3679 &quot;Cppcon&quot;


What does it mean to &quot;poison a function&quot; in C++?

In C++17, this code is illegal:

    constexpr int foo(int i) {
        return std::integral_constant&lt;int, i&gt;::value;
    }

That&#39;s because even if `foo` can be evaluated at compile-time, the compiler still needs to produce the instructions to execute it at runtime, thus making the template instantiation impossible.

In C++20 we will have `consteval` functions, which are required to be evaluated at compile-time, so the runtime constraint should be removed. Does it mean this code will be legal?

    consteval int foo(int i) {
        return std::integral_constant&lt;int, i&gt;::value;
    }

Will consteval functions allow template parameters dependent on function arguments?

I have a class `Dimension` which I defined (like all my classes) in a file Dimension.h:

    class Dimension
    {
    public:
    
    	constexpr Dimension() noexcept;
    
    	constexpr Dimension(int w, int h) noexcept;
    
    	int width;
    	int height;
    
    };

I thought I could, like in all my classes, put the definition in a separate Dimension.cpp:


    #include &quot;Dimension.h&quot;

    constexpr Dimension::Dimension() noexcept : width(0), height(0) {}
    
    constexpr Dimension::Dimension(int w, int h) noexcept : width(w), height(h) {}

But when I try to use the class, the compiler tells me:

warning: inline function &#39;`constexpr Dimension::Dimension()`&#39; used but never defined

and while linking:

undefined reference to &#39;`pong::graphics::Dimension::Dimension()`&#39;

(same with the other constructor)

If I define the class in the header like so:

    class Dimension
    {
    public:
    
    	constexpr Dimension() noexcept : width(0), height(0) {}
    
    	constexpr Dimension(int w, int h) noexcept : width(w), height(h) {}
    
    	int width;
    	int height;
    
    };

and omit the .cpp file, everything works fine.

I&#39;m using GCC 4.9.2. Why does separate definition not work?

Is it possible to declare constexpr class in a header and define it in a separate .cpp file?

Is it possible to declare a variable `extern constexpr` and define it in another file?

I tried it but the compiler gives error: 

&gt; Declaration of `constexpr` variable &#39;`i`&#39; is not a definition

in .h:

    extern constexpr int i;

in .cpp:

    constexpr int i = 10; 


How to declare constexpr extern?

Is there a difference between the following definitions?

    const     double PI = 3.141592653589793;
    constexpr double PI = 3.141592653589793;

If not, which style is preferred in C++11?

const vs constexpr on variables

Let me start by stating my intent. In the olden (C++) days, we would have code like:

    class C
    {
    public:
      enum {SOME_VALUE=27};
    };

Then we could use `SOME_VALUE` throughout our code as a compile time constant and wherever the compiler would see `C::SOME_VALUE`, it would just insert the literal 27.

Now days, it is seems more acceptable to change that code to something like:

    class C
    {
    public:
      static constexpr int SOME_VALUE=27;
    };

This looks much cleaner, gives `SOME_VALUE` a well defined type and seems to be the preferred approach as of C++11. The (unforseen at least for me) problem is that this also causes scenarios where `SOME_VALUE` needs to be made external. That is, in some cpp file somewhere, we need to add:

    constexpr int C::SOME_VALUE; // Now C::SOME_VALUE has external linkage

The cases that cause this seem to be when const references to `SOME_VALUE` are used, which happens quite often in C++ Standard Library code (See the example at the bottom of this question). I am using gcc 4.7.2 as my compiler by the way. 

Due to this dilemma, I am forced to revert back to defining `SOME_VALUE` as an enum (i.e., old school) in order to avoid having to add a definition to a cpp file for some, but not all of my static constexpr member variables. Isn&#39;t there some way to tell the compiler that `constexpr int SOME_VALUE=27` means that `SOME_VALUE` should be treated *only* as a compile time constant and never an object with external linkage? If you see a const reference used with it, create a temporary. If you see its address taken, generate a compile time error if that&#39;s what&#39;s needed, because it&#39;s a compile time constant and nothing more.

Here is some seemingly benign sample code that causes us to need to add the definition for `SOME_VALUE` in a cpp file (once again, tested with gcc 4.7.2):

    #include &lt;vector&gt;
    
    class C
    {
    public:
      static constexpr int SOME_VALUE=5;
    };
    
    int main()
    {
      std::vector&lt;int&gt; iv;
    
      iv.push_back(C::SOME_VALUE); // Will cause an undefined reference error
                                   // at link time, because the compiler isn&#39;t smart
                                   // enough to treat C::SOME_VALUE as the literal 5
                                   // even though it&#39;s obvious at compile time
    }

Adding the following line to the code at file scope will resolve the error:

    constexpr int C::SOME_VALUE;



enum vs constexpr for actual static constants inside classes

With C++17 we get inline variables.

One of the uses for them is to define constant fields in classes.

So what&#39;s the difference between these two constant definitions:

    class MyClass {
        static constexpr int myFirstVar = 10;
        static const inline int mySecondVar = 100;
    };

Of course `constexpr` makes `myFirstVar` implicitly inline.

What&#39;s the better choice here, to use `constexpr` or `inline`?

Note: when you don&#39;t need constness, then `inline` makes it easier. With `constexpr` you don&#39;t have that choice.

What&#39;s the difference between static constexpr and static inline variables in C++17?

Hello i&#39;m learning C++11, I&#39;m wondering how to make a constexpr 0 to n array, for example:

    n = 5;
    
    int array[] = {0 ... n};
    
so array may be `{0, 1, 2, 3, 4, 5}`



Create N-element constexpr array in C++11

It seems to me that having a &quot;function that always returns 5&quot; is breaking or diluting the meaning of &quot;calling a function&quot;.  There must be a reason, or a need for this capability or it wouldn&#39;t be in C++11.  Why is it there? 


    // preprocessor.
    #define MEANING_OF_LIFE 42
    
    // constants:
    const int MeaningOfLife = 42;
    
    // constexpr-function:
    constexpr int MeaningOfLife () { return 42; }

It seems to me that if I wrote a function that return a literal value, and I came up to a code-review, someone would tell me, I should then, declare a constant value instead of writing return 5.

When should you use constexpr capability in C++11?

For **defining compile-time constants** of integral types like the following (at function and class scope), which syntax is best?

    static const int kMagic = 64; // (1)
    constexpr int kMagic = 64;    // (2)

`(1)` works also for C++98/03 compilers, instead `(2)` requires at least C++11. Are there any other differences between the two? Should one or the other be preferred in modern C++ code, and why?


----------


**EDIT**

I tried this sample code with [Godbolt&#39;s CE][ce_code]:

    int main()
    {
    #define USE_STATIC_CONST
    #ifdef USE_STATIC_CONST
      static const int kOk = 0;
      static const int kError = 1;
    #else
      constexpr int kOk = 0;
      constexpr int kError = 1;
    #endif
      return kOk;
    }

and for the `static const` case this is the generated assembly by GCC 6.2:

    main::kOk:
            .zero   4
    main::kError:
            .long   1
    main:
            push    rbp
            mov     rbp, rsp
            mov     eax, 0
            pop     rbp
            ret

On the other hand, for `constexpr` it&#39;s:

    main:
            push    rbp
            mov     rbp, rsp
            mov     DWORD PTR [rbp-4], 0
            mov     DWORD PTR [rbp-8], 1
            mov     eax, 0
            pop     rbp
            ret

Although at `-O3` in both cases I get the same (optimized) assembly:

    main:
            xor     eax, eax
            ret


----------


**EDIT #2**

I tried this simple code [**(live on Ideone)**][code_2]:

    #include &lt;iostream&gt;
    using namespace std;
    
    int main() {
    	const int k1 = 10;
    	constexpr int k2 = 2*k1;
    	cout &lt;&lt; k2 &lt;&lt; &#39;\n&#39;;
    	return 0;
    }

which shows that `const int k1` is evaluated at _compile-time_, as it&#39;s used to calculate `constexpr int k2`.

However, there seems to be a _different_ behavior for `double`s. I&#39;ve created a separate question for that [here][constexpr_int_vs_double].

[CE_code]: https://godbolt.org/g/PdWdg6
[code_2]: https://ideone.com/WiXnua
[constexpr_int_vs_double]: https://stackoverflow.com/questions/41141734/initializing-constexpr-with-const-different-treatment-for-int-and-double






constexpr vs. static const: Which one to prefer?

Since it is possible that a function declared as constexpr can be called during run-time, under which criteria does the compiler decide whether to compute it at compile-time or during runtime? 

    template&lt;typename base_t, typename expo_t&gt;
    constexpr base_t POW(base_t base, expo_t expo)
    {
    	return (expo != 0 )? base * POW(base, expo -1) : 1;
    }
    
    int main(int argc, char** argv)
    {
    	int i = 0;
    	std::cin &gt;&gt; i;
    
    	std::cout &lt;&lt; POW(i, 2) &lt;&lt; std::endl;
    	return 0;
    }

In this case, i is unknown at compile-time, which is probably the reason why the compiler treats POW() as a regular function which is called at runtime. This dynamic however, as convenient as it may appear to be, has some impractical implications. For instance, could there be a case where I would like the compiler to compute a constexpr function during compile-time, where the compiler decides to treat it as a normal function instead, when it would have worked during compile-time as well? Are there any known common pitfalls?

When does a constexpr function get evaluated at compile time?

What is the difference between `if constexpr()` and `if()`?

Where and When can I use both of them?

Difference between &quot;if constexpr()&quot; Vs &quot;if()&quot;

    struct Test
    {
      static const int value = []() -&gt; int { return 0; } ();
    };
With gcc-4.6 I get something like, `error: function needs to be constexpr`. I have tried multiple combinations of putting `constexpr` at various places, but no luck.

Is `constexpr` supported for lambda functions as well (irrespective of `return` type specified or not) ? What is the correct syntax ?

Any work around possible ?

Is constexpr supported with lambda functions / expressions?

So noticed from this [page](http://en.cppreference.com/w/cpp/numeric/math) that none of the math functions in c++11 seems to make use of constexpr, whereas I believe all of them could be. So that leaves me with two questions, one is why did they choose not to make the functions constexpr. And two for a function like `sqrt` I could probably write my own constexpr, but something like sin or cos would be trickier so is there a way around it.

Constexpr Math Functions

This is a follow-up of this question: [Is it legal to declare a constexpr initializer_list object?](https://stackoverflow.com/questions/16063123/is-it-legal-to-declare-a-constexpr-initializer-list-object).

Since C++14, the `std::initializer_list` class has all of its methods marked with `constexpr`. It seems natural to be able to initialize an instance by doing 
`constexpr std::initializer_list&lt;int&gt; list = {1, 2, 3};` 
but Clang 3.5 complains about `list` not being initialized by a constant expression. 
[As dyp pointed out in a comment](https://stackoverflow.com/questions/16063123/is-it-legal-to-declare-a-constexpr-initializer-list-object#comment43416424_16067393), any requirement for `std::initializer_list` to be a literal type seem to have vanished from the specs.

What&#39;s the point of having a class fully defined as constexpr if we can&#39;t even initialize it as such? Is it an oversight in the standard and will get fixed in the future?

Why isn&#39;t `std::initializer_list` defined as a literal type?

Any function that consists of a return statement only could be declared
`constexpr` and thus will allow to be evaluated at compile time if all
arguments are `constexpr` and only `constexpr` functions are called in its body. **Is there any reason not to declare *any* such function `constexpr` ?**

Example:

      constexpr int sum(int x, int y) { return x + y; }
      constexpr i = 10;
      static_assert(sum(i, 13) == 23, &quot;sum correct&quot;);

**Could anyone provide an example where declaring a function `constexpr`
would do any harm?**


----------


Some initial thoughts:

Even if there should be no good reason for ever declaring a function 
not `constexpr` I could imagine that the `constexpr` keyword has a 
transitional role: its absence in code that does not need compile-time
evaluations would allow compilers that do not implement compile-time 
evaluations still to compile that code (but to fail reliably on code 
that needs them as made explict by using `constexpr`).

But what I do not understand: if there should be no good reason for 
ever declaring a function not `constexpr`, why is not **every** function
in the standard library declared `constexpr`? (You cannot argue
that it is not done yet because there was not sufficient time yet to
do it, because doing it for *all* is a no-brainer -- contrary to deciding for every single function if to make it `constexpr` or not.)
--- I am aware that [N2976](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2976.html)
deliberately not requires cstrs for many standard library types such
as the containers as this would be too limitating for possible 
implementations. Lets exclude them from the argument and just wonder:
once a type in the standard library actually has a `constexpr` cstr, why is not every function operating on it declared `constexpr`?

In most cases you also cannot argue that you may prefer not to declare a function `constexpr` simply because you do not envisage any compile-time usage: because if others evtl. will use your code, they may see such a use that you do not. (But granted for type trait types and stuff alike, of course.)

So I guess there must be a good reason and a good example for deliberately not declaring a function `constexpr`?

(with &quot;every function&quot; I always mean: every function that meets the 
requirements for being `constexpr`, i.e., is defined as a single 
return statement, takes only arguments of types with constexpr 
cstrs and calls only `constexpr` functions. Since C++14, [much more is allowed in the body of such function](https://en.cppreference.com/w/cpp/language/constexpr): e.g., *C++14 constexpr functions may use local variables and loops*, so an even wider class of functions could be declared `constexpr`.) 

The question [Why does `std::forward` discard `constexpr`-ness?](https://stackoverflow.com/questions/5098069/why-discards-stdforward-constexpr-ness) is a special case of this one.


Whyever **not** declare a function to be `constexpr`?

It seems obvious that constexpr implies const and thus it is common to see:

    constexpr int foo = 42; // no const here

However if you write:

    constexpr char *const str = &quot;foo&quot;;

Then GCC will spawn &quot;warning: deprecated conversion from string constant to ‘char*’&quot; if -Wwrite-string flag is passed.

Writing:

    constexpr const char *const str = &quot;foo&quot;;

solves the issue.

So are constexpr const and constexpr really the same?

constexpr const vs constexpr variables?

Maybe I missed something, but I can&#39;t find any hints: is there a constexpr ternary operator in C++17 equivalent to constexpr-if?

    template&lt;typename Mode&gt;
    class BusAddress {
    public:
        explicit constexpr BusAddress(Address device) : 
            mAddress(Mode::write ? (device.mDevice &lt;&lt; 1) : (device.mDevice &lt;&lt; 1) | 0x01) {}
    private:
        uint8_t mAddress = 0;    
    };

All Constexpr Solutions on Gang of Coders

Total of 36 Constexpr Solutions