不合格名称何时/为啥/如何在依赖基础中查找?
Posted
技术标签:
【中文标题】不合格名称何时/为啥/如何在依赖基础中查找?【英文标题】:When/why/how do unqualified names look in dependent base?不合格名称何时/为什么/如何在依赖基础中查找? 【发布时间】:2021-05-31 17:28:54 【问题描述】:对于 C++17,我在 [temp.dep]p3 中找到了这个措辞
在类或类模板的定义中,不检查依赖基类 (17.7.2.1) 的范围 在类模板或成员的定义点或在非限定名称查找期间 类模板或成员的实例化。
但看看最新的草稿(在 eel.is 上),情况似乎发生了变化。该文本不再出现在该位置,并且我不知道该规则是否仍然存在,或者以较弱的形式(如果它们是依赖的,可能会被查找,但如果找到基类成员则格式错误? ) 或根本没有!
【问题讨论】:
"但是查看最新的草案(在 eel.is 上)," 请注意,所述草案包含 C++20 后的更改,可能与 C 的内容不准确++20 是。 This particular draft更准确地反映了C++20的内容,没有后20的变化。 它还包含有问题的语句。所以你肯定是在谈论 C++20 后的变化。 @Nicol 谢谢!在那个版本中,该段落仍然存在(如 p4)。不幸的是,快速浏览 cwg 缺陷和问题列表并没有提供任何导致删除的原因!也许该段落“溶解”到其他地方的文本中。 我知道后 C++20 在整合范围规则方面做了很多工作。他们搬到了哪里,我不能说。 【参考方案1】:什么都没有改变。相关规则为now[class.member.lookup]/4:
计算每个直接非依赖([temp.dep.type])基类中N的查找集[…]
因此不需要对 [temp] 中的名称查找规则进行特殊覆盖。
【讨论】:
感谢权威回答。我不知道事情被清理了这么多!但是我发现了注释“如果 T 是一个实例化的类,它的基类不依赖。”。我对新规则完全没有经验,但这并不意味着像“auto x = &operator T;”这样的名称在实例化的类中可能会从依赖基类实例化的类模板特化中找到成员声明? 啊,搞砸了!如果地址被占用,它必须是合格的......如果我把它称为'operator T()',依赖调用规则就会启动并且只在实例化上下文中启用ADL。再次感谢! @JohannesSchaub-litb:确实,将operator T
设为从属名称(即使不合格)是同一篇论文中的另一个修复方法,以确保此类查找能够正常工作。
我很高兴 DR#554 终于得到修复。只用了 15 年!
@JohannesSchaub-litb:正如您所发现的,[basic.link] 也需要重写。 C++20 确实放弃了 types 的过时概念,其链接与其名称分开,因此将来可以将链接改写为与实体有关,而不是与它们的名称有关。以上是关于不合格名称何时/为啥/如何在依赖基础中查找?的主要内容,如果未能解决你的问题,请参考以下文章
为啥我的 iOS 9 iPhone 在 Xcode 6.4 中显示为不合格设备?
在 SwiftUI 中,我如何知道 Picker 选择何时更改?为啥 didSet 不起作用?
何时/啥/为啥/如何在应用程序(应用程序:willFinishLaunchingWithOptions :) 中使用来自 launchOptions 的 UIApplicationOptionsURL