关于 std::less 行为的问题
那里发生了什么？
#include <functional>
namespace A {
struct Class { };
}
bool operator<(const A::Class& a, const A::Class& b)
{ return false; }
int main()
{
std::less<A::Class>()(A::Class(), A::Class());
return 0;
}
这样编译就ok了。但如果我使用.
#include <set>
我收到错误：
g++ test.cc -o test
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/bits/stl_tree.h:64:0,
from /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/set:60,
from lookup.cc:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/bits/stl_function.h: In member function 'bool std::less<_Tp>::operator()(const _Tp&, const _Tp&) const [with _Tp = A::Class]':
test.cc:15:49: instantiated from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/bits/stl_function.h:230:22: error: no match for 'operator<' in '__x < __y'
make: *** [test] Error 1
What is happening there?
#include <functional>
namespace A {
struct Class { };
}
bool operator<(const A::Class& a, const A::Class& b)
{ return false; }
int main()
{
std::less<A::Class>()(A::Class(), A::Class());
return 0;
}
This is compiled ok. But if I use.
#include <set>
I got errors:
g++ test.cc -o test
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/bits/stl_tree.h:64:0,
from /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/set:60,
from lookup.cc:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/bits/stl_function.h: In member function 'bool std::less<_Tp>::operator()(const _Tp&, const _Tp&) const [with _Tp = A::Class]':
test.cc:15:49: instantiated from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/include/g++-v4/bits/stl_function.h:230:22: error: no match for 'operator<' in '__x < __y'
make: *** [test] Error 1
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
查找失败的原因是
set在std命名空间中为std::set引入了一个operator<隐藏所有其他全局运算符。std::less实例化中<的查找发生在std命名空间内的作用域内。std命名空间之外的任何operator<变得可见的唯一方法是 ADL 启动，并且这种情况仅发生在最近的封闭命名空间中。如果不包含
std命名空间中不会引入operator<（这可能与实现相关）operator<，因此非 ADL 查找规则仍然可以找到采用A::Class的全局operator<。更正：正如 @JohannesSchaub 指出的，只有当
operator<的声明发生在x < y之类的表达式中，会搜索名为operator<的候选函数，这是 unqualified-id 的一种特殊形式。 )就目前情况而言，重载的
operator<不应被视为带有或不带有The reason that the lookup fails is that
setintroduces anoperator<forstd::setin thestdnamespace that hides all other globaloperator<.The lookup of
<in the instantiation ofstd::lesshappens inside a scope inside thestdnamespace. The only way that anyoperator<outside ofstdnamespace will become visible is if ADL kicks into action and this only happens for the nearest enclosing namespace.Without including
<set>, there is nooperator<introduced (and this is probably implementation dependent) in thestdnamespace that hides the globaloperator<and hence the non-ADL lookup rules can still find the globaloperator<which takeA::Class.Correction: As @JohannesSchaub points out, this analysis would only be correct if the declaration of
operator<occurred before<functional>(wherestd::lessis defined) was first included. As it is, the only overloads of a function called through an unqualified-id that should be visible to non-ADL lookup inside a template definition are those visible at the point of definition. Definitions introduced between the point of definition and the point of instantiation should only be visible for ADL lookup. (In an expression such asx < ycandidate functions namedoperator<are searched for and this is one particular form of unqualified-id.)As it stands, the overloaded
operator<should not be considered a candidate with or without the<set>include, although these corner cases in the lookup rules are not always handled correctly by all compilers.该
操作符<也应该位于命名空间A中，否则无法查找。细节：
首先，只需从
main()调用两个Class对象上的operator<，甚至实现您自己的less> 当然，无论operator<是否与Class位于同一命名空间中，它都可以工作，尽管它应该位于同一命名空间中，因为每个人都是这样，包括库的实现者，期望。 gcc 和 MSVC 2010（正如我刚刚测试的那样）在它们的标准库中都包含了几个额外的operator<，编译器无法解析这些操作符。gcc 4.5.2 的错误消息具有误导性。使用预发行版 4.6 进行相同的编译，我得到了更具体的信息
顺便说一句，SunCC（同时具有 rw 和 stlport4）可以干净地编译它，甚至创建一个可用的
std::set。That
operator<should be innamespace Aas well, otherwise it cannot be looked up.Details:
First of all, simply calling
operator<on twoClassobjects frommain(), or even implementing your ownlessof course works whetheroperator<is in the same namespace asClassor not, although it should be in the same namespace since that's what everyone, including the implementors of the libraries, expects. Both gcc and MSVC 2010 (as I just tested) include several additionaloperator<'s in their standard libraries, between which the compiler fails to resolve.gcc 4.5.2's error message is misleading. Compiling the same with a pre-release 4.6, I get the more specific
Incidentally, SunCC (with both rw and stlport4) compiles this cleanly and even creates a usable
std::set<A::Class>.您的
operator<重载需要与Class位于同一命名空间中（即，它也需要位于A命名空间中）。C++ 具有复杂的名称查找规则。更有趣的“功能”之一是“参数相关查找”或 ADL，其中可以在与函数参数关联的命名空间中查找名称。对于没有基类且不是嵌套类的类（例如
Class），唯一关联的命名空间是该类所在的命名空间。因此，与
Class关联的唯一命名空间是A，因此在依赖于参数的运算符查找操作符时，仅搜索过载。A命名空间A命名空间;Charles Bailey 的回答很好地解释了为什么您只在包含时才看到问题<代码><设置>。
Your
operator<overload needs to be in the same namespace asClass(that is, it also needs to be in theAnamespace).C++ has complex name lookup rules. One of the more interesting "features" is "argument-dependent lookup," or ADL, where names can be looked up in namespaces associated with a function's arguments. For a class that has no base classes and isn't a nested class, like your
Class, the only associated namespace is the namespace within which the class is located.So, the only namespace associated with
ClassisA, so only theAnamespace is searched during argument-dependent lookup for anoperator<overload.Charles Bailey's answer provides a good explanation of why you only see the problem when including
<set>.