SFINAE 能否检测私人访问违规行为?
我想知道如果我测试某个类的某个成员并且该成员是私有的,sfinae 会做出什么反应?它会严重出错还是会说“ok”或者会以 sfinae 方式出错?
I wonder whether if i test for some member of a class and the member is private what will sfinae respond? Will it error out hard or will it say ok or will it error out in the sfinae way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
是的。
编辑:来自§14.8.2 [temp.deduct]的C++11标准引用
这对我来说意味着
private
可以触发 SFINAE 错误。阅读:“直接上下文”对我来说不太清楚......但这并不矛盾我的观点:)
编辑结束
所以在我看来它将以 SFINAE 方式出错,Clang 的摘录进一步证实了这一点:
在 SFINAE 的情况下,存在关于访问控制的特殊情况。
Yes.
EDIT: C++11 Standard quote from §14.8.2 [temp.deduct]
This suggests to me that
private
can trigger an SFINAE error. Reading on:The "immediate context" is not so clear to me... but it does not contradict my point :)
end of EDIT
So it seems to me that it will error out in an SFINAE way, this is further confirmed by this excerpt from Clang:
There are special cases with regard to Access Control in the case of SFINAE.
不。我正在路上,没有可以引用的标准,但 sfinae 发生在编译阶段,编译器检查名称是否存在,并在稍后的阶段进行访问控制。
这类似于重载解析,其中考虑所有名称,并且私有的匹配更好,但不会编译,尽管还有另一个匹配“ok”但不是私有的。
补充:
核心问题 1170 说:
所以我的解释是这在 C++03 中是不可能的,但 C++11 使它成为可能。
No. I am on the road and don't have a standard to quote with me, but sfinae takes places in the phase of compilation where the compiler checks if the name exists at all, and in a later phase access control takes place.
This is similar to overload resolution, where all names are considered, and a match that is private is better, but won't compile, although there is another match that would be "ok" but not private.
Addition:
Core issue 1170 says:
So my interpretation is that this is impossible in C++03, but C++11 made it possible.
我不这么认为。
因此,首先发生重载解析,然后应用访问控制。
I don't think so.
So overload resolution occurs first, then access control is applied.
下面是一个实现 is_comparable 并处理潜在私有运算符 == 的示例。 g++-4.7 对此感到窒息,但 g++-4.8 和 clang++ 3.4 在 C++11 模式下正确处理它。
Here is an example that implements is_comparable and handles a potentially private operator==. g++-4.7 chokes on this, but g++-4.8 and clang++ 3.4 handle it correctly in C++11 mode.