c++ - 从整型常量表达式转换为空指针

Question

考虑以下代码:

#include <memory>

void f( std::shared_ptr<int> ) {}

int main()
{
    f( 0 );               // compiles fine in gcc and clang
    f( 1 - 1 );           // compiles fine in gcc, fails in clang
    constexpr int i = 0;
    f( i );               // fails to compile in gcc and clang
    f( i - 0 );           // compiles fine in gcc, fails in clang
}

为什么只有 f( i ) 编译失败，而 i 应该被评估为值为 0 的编译时间常数？

PS 使用 g++ v 5.1.0 检查，它在 c++11 和 c++14 模式下接受除 f(i); 之外的所有变体 PPS 使用 clang 3.7 检查，它在 c++11 和 c++14 模式下拒绝除文字 0 之外的所有变体

Answer 1

这是一个 gcc 错误。 Defect report 903: Value-dependent integral null pointer constants 这是针对 C++11 的缺陷报告(它具有 CD3 状态)，使得只有整数文字 0 被视为空指针常量。

它更改了 4.10 [conv.ptr] 段落 1 部分以及其他更改:

A null pointer constant is an integral constant expression (5.19 [expr.const]) prvalue of integer type that evaluates to zero [...]

到:

A null pointer constant is an integer literal (2.14.2 [lex.icon]) with value zero [...]

这被列为与 C++03 的不兼容性，来自 C.2.2 第 4 条:标准转换 [diff.cpp03.conv] 部分:

Change: Only literals are integer null pointer constants
Rationale: Removing surprising interactions with templates and constant expressions
Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this International Standard, as the following example illustrates:

void f(void *); // #1
void f(...); // #2
template<int N> void g() {
  f(0*N); // calls #2; used to call #1
}

以下 gcc 错误报告 [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer表明 gcc 团队最初认为这是 C++17 的更改，但后来将其更改为在 C++11 中生效。

我们可以在 gcc(6.0) 的头版本中看到这是固定的 ( see it live ) 并为 clang 所做的所有情况生成诊断: p>

error: could not convert '(1 - 1)' from 'int' to 'std::shared_ptr<int>'
 f( 1 - 1 );           // compiles fine in gcc, fails in clang
    ~~^~~

error: could not convert 'i' from 'const int' to 'std::shared_ptr<int>'
 f( i );               // fails to compile in gcc and clang
      ^

error: could not convert '(0 - 0)' from 'int' to 'std::shared_ptr<int>'
 f( i - 0 );           // compiles fine in gcc, fails in clang
    ~~^~~