所有其他的答案都很棒，我只是想给一个很酷的例子，你可以用constexpr做一件很棒的事情。See-Phit (https://github.com/rep-movsd/see-phit/blob/master/seephit.h)是一个编译时HTML解析器和模板引擎。这意味着您可以放入HTML，然后取出能够操作的树。在编译时进行解析可以提供一些额外的性能。

从github页面的例子:

#include <iostream>
#include "seephit.h"
using namespace std;



int main()
{
  constexpr auto parser =
    R"*(
    <span >
    <p  color="red" height='10' >{{name}} is a {{profession}} in {{city}}</p  >
    </span>
    )*"_html;

  spt::tree spt_tree(parser);

  spt::template_dict dct;
  dct["name"] = "Mary";
  dct["profession"] = "doctor";
  dct["city"] = "London";

  spt_tree.root.render(cerr, dct);
  cerr << endl;

  dct["city"] = "New York";
  dct["name"] = "John";
  dct["profession"] = "janitor";

  spt_tree.root.render(cerr, dct);
  cerr << endl;
}

它可以实现一些新的优化。Const传统上是类型系统的提示，不能用于优化(例如，Const成员函数可以合法地const_cast并修改对象，因此Const不能用于优化)。

Constexpr表示表达式真的是常量，前提是函数的输入是const。考虑:

class MyInterface {
public:
    int GetNumber() const = 0;
};

如果这在其他模块中公开，编译器不能相信GetNumber()在每次调用时不会返回不同的值——甚至在两次调用之间没有非const调用的情况下也不会返回不同的值——因为const可能已经在实现中被丢弃了。(显然，任何这样做的程序员都应该被枪毙，但语言允许这样做，因此编译器必须遵守这些规则。)

添加constexpr:

class MyInterface {
public:
    constexpr int GetNumber() const = 0;
};

编译器现在可以应用优化，缓存GetNumber()的返回值，并消除对GetNumber()的额外调用，因为constexpr是一个更强的保证，返回值不会改变。

它在某些方面很有用

// constants:
const int MeaningOfLife = 42;

// constexpr-function:
constexpr int MeaningOfLife () { return 42; }

int some_arr[MeaningOfLife()];

将它与特质类或类似的类联系起来，它会变得非常有用。

这里的许多回答似乎有些相反，或者把安静的部分大声说出来，把吵闹的部分小声说出来。关于constexpr你需要知道的一件关键的事情是:

// This guarantees only that the value of "MeaningOfLife" can not be changed
// from the value calculated on this line by "complex_initialization()"
// (unless you cast away the const of course, don't do that).
// Critically here, everything happens at *runtime*.
const int MeaningOfLife = complex_initialization(1234, 5678, "hello");

// This guarantees that "MeaningOfLife" is fully evaluated and "initialized"
// *at compile time*.  If that is not possible due to complex_initialization()
// not being evaluatable at compile time, the compiler is required to abort
// compilation of the program.
// Critically here, to put a fine point on it, everything happens at
// *compile time*, guaranteed.  There won't be a runtime call to
// complex_initialization() at all in the final program.
constexpr int MeaningOfLife = complex_initialization(1234, 5678, "hello");

注意，是左边的常量使保证有存在的理由。当然，这取决于你是否能确保右边的值在编译时被求出来，重要的是，仅仅声明一个函数constexpr本身并不能做到这一点。

因此，您的问题的答案是，当您需要或希望它的初始化(右边发生的所有事情)完全在编译时发生或中断构建时，您应该声明一个变量constexpr。

简介

引入Constexpr并不是为了告诉实现可以在需要常量表达式的上下文中求值;一致性实现在c++ 11之前就已经证明了这一点。

实现无法证明的是某段代码的意图:

开发人员想用这个实体表达什么? 我们是否应该盲目地允许在常量表达式中使用代码，仅仅因为它碰巧有效?

没有警察，这个世界将会怎样?

假设您正在开发一个库，并意识到您希望能够计算区间(0,N]中每个整数的和。

int f (int n) {
  return n > 0 ? n + f (n-1) : n;
}

缺乏意图

如果在转换过程中传递的参数是已知的，编译器可以很容易地证明上述函数在常量表达式中是可调用的;但你并没有宣布这是一个意图——这只是碰巧的情况。

现在另一个人来了，读取你的函数，做和编译器一样的分析;“哦，这个函数在常量表达式中可用!”，然后写了下面的代码。

T arr[f(10)]; // freakin' magic

优化

作为一个“了不起的”库开发人员，您决定f应该在被调用时缓存结果;谁会想要一遍又一遍地计算同一组值呢?

int func (int n) { 
  static std::map<int, int> _cached;

  if (_cached.find (n) == _cached.end ()) 
    _cached[n] = n > 0 ? n + func (n-1) : n;

  return _cached[n];
}

结果

通过引入愚蠢的优化，您破坏了在需要常量表达式的上下文中对函数的所有使用。

您从未承诺过函数在常量表达式中是可用的，没有constexpr，就无法提供这样的承诺。

为什么我们需要constexpr?

constexpr的主要用途是声明意图。

如果一个实体没有被标记为constexpr——它从未打算在常量表达式中使用;即使是这样，我们也依赖编译器来诊断这样的上下文(因为它忽略了我们的意图)。

你的基本例子和常数本身的例子是一样的。为什么要使用

static const int x = 5;
int arr[x];

over

int arr[5];

因为这样更容易维护。使用constexpr写和读要比现有的元编程技术快得多。