decltype和类成员名称之间的交互，隐藏外部名称

本文介绍了decltype和类成员名称之间的交互，隐藏外部名称的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

此代码

int clash; struct Foo { decltype（clash）clash; };

在clang上静默编译，但无法在gcc上编译出错

错误：声明'int Foo :: clash'[-fpermissive]

错误： 'clash'from'int clash'[-fpermissive]

似乎需要2个成分才能产生错误： p>

阴影必须由类成员完成（如果是函数的局部作用域，则没有问题）。

必须在阴影作用域中使用

decltype（[shadowed name]

我的问题有两个：

gcc是否拒绝此代码？

解决方案

gcc 是正确的程序是不成形的，虽然这个特殊的违规不需要诊断，所以 clang 不必提供一个。

如果我们看看C ++ 11标准（最接近的草稿将 N3337 ） 3.3.7 类范围它说：

类S中使用的名称N，在上下文中声明，并在S的完成范围内重新求值。违反此规则需要诊断。

并且下一条规则说：

如果在类中重新排序成员声明， b程序在（1）和（2）下，程序是不成形的，诊断是不需要。

有意义的是，我们想要防止在一个类中的声明重新排序给出一个不同的程序的情况。很高兴知道这两条规则是否冗余。

该部分还提供了以下示例：

枚举{i = 1} class X { char v [i]; //错误：i引用:: i //但是当重新评估时是X :: i int f（）{return sizeof（c）; } // OK：X :: c char c; enum {i = 2}; };

如果我们使用 gcc （ 查看实时 ），我们得到几乎完全相同的错误您的代码产生的代码：

错误：声明'i'[-fpermissive] enum {i = 2 }; ^ 错误：更改'i'的意义从'< anonymous enum> i'[-fpermissive] enum {i = 1};

This code

int clash; struct Foo { decltype(clash) clash; };

compiles silently on clang, but fails to compile on gcc giving the errors

error: declaration of 'int Foo::clash' [-fpermissive]

error: changes meaning of 'clash' from 'int clash' [-fpermissive]

It seems that 2 ingredients are required for the error to arise:

The shadowing must be done by a class member (no problem if it's a function's local scope).

decltype([shadowed name]) must be used in the shadowing scope before the declaration of [shadowing name].

My question is twofold:

Is gcc justified in rejecting this code?

Where does it say so in the standard?

解决方案

gcc is correct the program is ill-formed, although this particular violation does not require a diagnostic so clang does not have to provide one.

If we look at the C++11 standard(The closest draft would be N3337) section 3.3.7 Class scope it says:

A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule.

and the next rule says:

If reordering member declarations in a class yields an alternate valid program under (1) and (2), the program is ill-formed, no diagnostic is required.

It makes sense we would want to prevent situations where reordering the declarations in a class give a different program. It is curious whether these two rules are redundant or not.

The section also provides the following example:

enum { i = 1 }; class X { char v[i]; // error: i refers to ::i // but when reevaluated is X::i int f() { return sizeof(c); } // OK: X::c char c; enum { i = 2 }; };

and if we try this example with gcc (see it live), we get an almost identical error to one your code produces:

error: declaration of 'i' [-fpermissive] enum { i = 2 }; ^ error: changes meaning of 'i' from '<anonymous enum> i' [-fpermissive] enum { i = 1 };