下面的代码被 clang 和 gcc 都拒绝

template<typename T>
void f(T t)
{
    t.Dependent::f(); // clang accepts, gcc rejects
    t.operator Dependent*(); // both reject
}

struct Dependent
{
     void f();
};

struct A : Dependent
{
     operator Dependent*();
};

template void f<A>(A);

我对标准的阅读表明这两种表达方式都应该被接受。

在这两种情况下，Dependent 只能是类型名称。

在这两种情况下，名称Dependent 都将“在对象表达式的类中查找”t。由于 t 是一个依赖于类型的表达式，查找应该推迟到模板被实例化。

有什么我想念的吗？

编辑:如果打算让这样的名称不依赖，那么这个决定的理由是什么？我可以看到，如果实现者不必推迟对 t.operator X::Dependent* 或 t.X::Dependent::f 其中 X 可以是命名空间或类型名称。我不清楚这是当前措辞有意还是无意的副作用。

C++ 工作草案 N3337 的相关引述:

3.4.5 Class member access [basic.lookup.classref]

If the id-expression in a class member access is a qualified-id of the form class-name-or-namespace-name::... the class-name-or-namespace-name following the . or -> operator is first looked up in the class of the object expression and the name, if found, is used. Otherwise it is looked up in the context of the entire postfix-expression. [ Note: See 3.4.3, which describes the lookup of a name before ::, which will only find a type or namespace name. —end note ]

If the id-expression is a conversion-function-id, its conversion-type-id is first looked up in the class of the object expression and the name, if found, is used. Otherwise it is looked up in the context of the entire postfix-expression. In each of these lookups, only names that denote types or templates whose specializations are types are considered.

14.6.2 Dependent names [temp.dep]

Inside a template, some constructs have semantics which may differ from one instantiation to another. Such a construct depends on the template parameters. In particular, types and expressions may depend on the type and/or value of template parameters (as determined by the template arguments) and this determines the context for name lookup for certain names. Expressions may be type-dependent (on the type of a template parameter) or value-dependent (on the value of a non-type template parameter).

[...]

Such names are unbound and are looked up at the point of the template instantiation (14.6.4.1) in both the context of the template definition and the context of the point of instantiation.

14.6.2.1 Dependent types [temp.dep.type]

A name is a member of an unknown specialization if it is

[...]

— An id-expression denoting the member in a class member access expression (5.2.5) in which either

— the type of the object expression is the current instantiation, the current instantiation has at least one dependent base class, and name lookup of the id-expression does not find a member of the current instantiation or a non-dependent base class thereof; or

— the type of the object expression is dependent and is not the current instantiation.

[...]

A type is dependent if it is

— a member of an unknown specialization,

最佳答案

1

我认为您的第一个案例 t.Dependent::f 是这样工作的。首先，我相信(意思是，我不完全确定)14.6.2.1p5 应该说“unqualified-id”而不是“id-expression”。但与此无关，您的名字 Dependent::f 实际上是由两个名字组成的(在标准中，每个嵌套的 nested-name-specifier 后跟一个成员名称为“qualified-id”，即使在语法上，这些都不是合格的 id 产品。因此名称 foo::bar::baz 是一个合格的 id，但也包含 1 个其他“合格的 id”。

Dependent 和 Dependent::f。前者不是“表示类成员访问表达式中的成员的 id 表达式”，因此您不能简单地将适用于 Dependent::f 的规则应用到 依赖。

Dependent 因此是非依赖的，尽管需要在依赖类型中查找它，但必须在定义时找到它。我个人认为我们应该有一个子句说“当查找限定符依赖于类型的限定 ID 时，名称查找会产生一个空结果。”，以优雅地处理这些“强制名称查找立即完成” .所以无论如何，最后，我认为你的第一个案例是错误的，因为没有找到 Dependent (第 3.4 条不能仅仅在第 14 条的头上自行决定名称实际上是依赖的).

2

对于您的另一种情况，operator Dependent，事情就简单多了。您再次拥有两个名称，Dependent 和 operator Dependent。同样，我没有发现任何说明 Dependent 是这里的依赖名称(我不确定这是否是错误的。这超出了我的范围)。

运算符函数名称的名称查找比较(例如，名称查找哈希表的相等函数)是“它们是由相同类型构成的转换函数 ID”(3.8)。这意味着为了形成名称本身(还没有进行名称查找!)，您不仅必须像标识符那样给出词汇拼写，而且还必须提供类型标识，这需要由依赖。

t.operator Dependent* 中依赖 id-expression 的查找被延迟仅仅意味着语义类型比较被延迟。试试这个，应该可以正常工作

struct Dependent; // forward decl at global scope
t.operator Dependent*(); // in function template

你的跟进

If it is intended that such a name is not dependent, what is the rationale for this decision? I can see that it makes life easier for the implementor if they do not have to defer evaluation of a construct like t.operator X::Dependent* or t.X::Dependent::f where X could be either a namespace or a type name.

我不知道其中的原理，但我认为您已经给出了一个很好的观点。这看起来非常符合在查找非限定名称时跳过依赖基类的规则。我认为适用于该案例的理由也适用于该案例。对于 程序员 来说，它更容易在函数模板上进行推理，尤其是。

struct Dependent;

template<typename T>
void f(T t)
{
    t.Dependent::f();
    t.operator Dependent*();
}

代码看起来不错，但是如果 T 碰巧有一个 Dependent 成员，突然 Dependent 会有一个不同的绑定(bind)(因为首先我们被告知查看 t 的类，然后查看周围的范围)。根据我目前对模板规则的理解，上面总是引用周围范围的 Dependent，所以上面的代码对于那个陷阱是“安全的”。

关于c++ - 是否应该为类成员访问表达式中的依赖类/命名空间名称延迟名称查找？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18218475/