c++ - 编译时是否需要短路评估规则？

Question

程序 A 产生编译错误(正如预期的那样)，因为 isFinite 是用非整数类型调用的。

程序A

#include <iostream>

class Foo {};

template<typename T>
bool isFinite(const T& t)
{
    static_assert(std::is_integral<T>::value, "Called isFinite with a non-integral type");
    return false;
}

int main()
{
    Foo f;
    std::cout << "Foo is finite? " << ((isFinite(f)) ? "yes" : "no") << "\n";

    return 0;
}

然而，稍作修改(参见程序 B)允许程序编译 (Visual Studio 2013) 并产生以下输出。

程序 B Visual Studio 2013 输出

Foo 是有限的？是的

计划B

#include <iostream>

class Foo {};

template<typename T>
bool isFinite(const T& t)
{
    static_assert(std::is_integral<T>::value, "Called isFinite with a non-integral type");
    return false;
}

int main()
{
    Foo f;
    std::cout << "Foo is finite? " << ((true || isFinite(f)) ? "yes" : "no") << "\n";

    return 0;
}

程序 B 似乎在逻辑 OR 运算上短路并且没有尝试编译表达式的其余部分。 但是，此应用程序不使用 g++ 4.8.3 (g++ -std=c++11 -o main main.cpp) 进行编译。我得到以下输出。

main.cpp: In instantiation of 'bool isFinite(const T&) [with T = Foo]':
main.cpp:15:56:   required from here
main.cpp:8:2: error: static assertion failed: Called isFinite with a non-integral type
  static_assert(std::is_integral<T>::value, "Called isFinite with a non-integral type");
  ^

我的直觉让我相信编译失败是正确的行为但奇怪的是 Visual Studio 2013 编译成功。我的直觉是基于这样一个事实，即预计无法编译以下代码。

#include <iostream>

struct Foo
{
    void doOperation1() {}
    void doOperation2() {}
};

struct Bar
{
    void doOperationA() {}
    void doOperation2() {}
};

template<typename T>
void performOperation(T& t, bool value)
{
    if (value)
    {
        t.doOperation1();
    }
    else
    {
        t.doOperation2();
    }
}

int main()
{
    Foo f;
    performOperation(f, true);
    performOperation(f, false);

    Bar b;
    performOperation(b, false); // Fails to compile (as expected)

    return 0;
}

重述问题

逻辑运算符是否应该在编译时遵守短路评估规则(即，程序 B 的预期编译行为是什么)？

Answer 1

短路不应该编译true || (whatever_ill_formed) . isFinite<Foo>作为表达式的一部分被实例化，在实例化期间它应该被编译并且在编译期间它应该静态断言。之后编译器可能永远不会计算 isFinite<Foo>(f)因为短路但静态断言不应在此期间发生。

目前还不清楚为什么 Visual Studio 2013 会编译程序 B。标准只允许在模板从未实例化时绕过模板的语法检查。即使这样，代码仍然是错误的，只需要诊断即可。缺陷的背后可能是 Visual C++ 中的相同内部问题，它不允许 Microsoft 实现 constexpr .

编辑 我根据@zneak 的要求从标准中添加了一些语言律师文本

3.2/3

A function whose name appears as a potentially-evaluated expression is odr-used if it is the unique lookup result or the selected member of a set of overloaded functions (3.4, 13.3, 13.4), unless it is a pure virtual function and its name is not explicitly qualified. [Note: This covers calls to named functions (5.2.2), operator overloading (Clause 13), user-defined conversions (12.3.2), allocation function for placement new (5.3.4), as well as non-default initialization (8.5). A constructor selected to copy or move an object of class type is odr-used even if the call is actually elided by the implementation (12.8). —end note]

5.13/1

The || operator groups left-to-right. The operands are both contextually converted to bool (Clause 4). It returns true if either of its operands is true, and false otherwise. Unlike |, || guarantees left-to-right evaluation; moreover, the second operand is not evaluated if the first operand evaluates to true.

7.1/4

In a static_assert-declaration the constant-expression shall be a constant expression (5.19) that can be contextually converted to bool (Clause 4). If the value of the expression when so converted is true, the declaration has no effect. Otherwise, the program is ill-formed, and the resulting diagnostic message (1.4) shall include the text of the string-literal, except that characters not in the basic source character set (2.3) are not required to appear in the diagnostic message.

14.7.1/3

Unless a function template specialization has been explicitly instantiated or explicitly specialized, the function template specialization is implicitly instantiated when the specialization is referenced in a context that requires a function definition to exist.