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;
}

Program 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.