How to fully bypass `error: no match for ‘operator==’`?
How to fully bypass `error: no match for ‘operator==’`?
我正在使用一个名为 SlideSort
的程序,该程序在使用 GCC 6.3.0 的最新 Debian 系统上不再编译。相反,它会抛出以下错误:
mstree.cpp:228:11: error: no match for ‘operator==’ (operand types are ‘std::ofstream {aka std::basic_ofstream<char>}’ and ‘long int’)
if(dFile==NULL){
^
我不是 C 程序员,我试图通过温和地告诉编译器代码是旧的来绕过这个问题;据我了解,这大致就是 GCC 的选项 -std=c++98
所做的。 (请参阅 GitHub 的 issue tracker 以获取 Makefile 的补丁)。
然后代码编译。但它在某些极端情况下会出现段错误(测试数据和命令在 GitHub 的 issue tracker 中可用)。当程序使用 GCC 4.9.4 编译时,相同的测试命令工作正常。
因此,将 -std=c++98
传递给 GCC 要么是不够的,要么是完全错误的想法。是否有替代方法可以在旧系统上编译或将代码更新为最新标准(我自己做不到)?
在不知道其余代码的情况下,您可以尝试改写该行,例如:
如果(!dFile)
看看接下来会发生什么。
我不知道为什么这段代码有效。在任何版本的 C++ 标准中,标量流对象都无法与整数 或 到 nullptr_t
相媲美。话虽这么说,你的问题不是如何修复你找到的代码,而是如何绕过错误。 我不建议在生产代码中执行我将要在此处说的内容。这是一个 hack,它只是为了让像这样的不寻常的库工作而设计的。
==
运算符可以在任何 class 之外定义为独立函数。您正在使用的库将 std::ofstream
与 long int
进行比较。让我们使该比较有效。
bool operator==(const std::ofstream&, long int) {
return false;
}
现在您的代码可以编译了。但它可能 运行 不正确。您可以通过检查 std::ofstream
是否真实来尝试使比较更智能。
bool operator==(const std::ofstream& out, long int n) {
return (bool)out == (bool)n;
}
现在更聪明了。但这里没有灵丹妙药。您获得的代码 无法正常工作并且不是标准 C++,因此没有完全可靠的方法可以在不更改实际库代码的情况下使其正常工作。所以我的建议是分叉存储库并自己修复断行代码。
我的猜测是这个 (if(dFile==NULL){
) if 条件试图检查文件是否已成功打开以进行写入,如果是,则使用 c++ 中可用的函数 is_open
。所以只需将条件替换为if (dFile.is_open())
。这应该可以解决问题。
在 C++ 98 中,流曾经有一个 operator void*()
来检查流状态。当流处于错误状态时,它返回一个空指针。事实证明,这种隐式转换在奇怪的地方意外调用时会导致一些意想不到的结果。
因此在获得显式运算符的 C++11 中,它变成了 explicit operator bool()
。 returns true
表示状态良好,false
表示流处于失败状态。
作为explicit
它也只能用在需要bool
的地方。这从旧运算符中删除了大部分意外转换。
所以 if(dFile==NULL)
,测试流的非良好状态,现在写成 if (!dFile)
。
实际上,测试 if (dfile)
(良好状态)和 if (!dFile)
(非良好状态)一直有效。从来不需要与 NULL
进行比较,它只是在运算符返回 void*
.
时才起作用
我正在使用一个名为 SlideSort
的程序,该程序在使用 GCC 6.3.0 的最新 Debian 系统上不再编译。相反,它会抛出以下错误:
mstree.cpp:228:11: error: no match for ‘operator==’ (operand types are ‘std::ofstream {aka std::basic_ofstream<char>}’ and ‘long int’)
if(dFile==NULL){
^
我不是 C 程序员,我试图通过温和地告诉编译器代码是旧的来绕过这个问题;据我了解,这大致就是 GCC 的选项 -std=c++98
所做的。 (请参阅 GitHub 的 issue tracker 以获取 Makefile 的补丁)。
然后代码编译。但它在某些极端情况下会出现段错误(测试数据和命令在 GitHub 的 issue tracker 中可用)。当程序使用 GCC 4.9.4 编译时,相同的测试命令工作正常。
因此,将 -std=c++98
传递给 GCC 要么是不够的,要么是完全错误的想法。是否有替代方法可以在旧系统上编译或将代码更新为最新标准(我自己做不到)?
在不知道其余代码的情况下,您可以尝试改写该行,例如: 如果(!dFile)
看看接下来会发生什么。
我不知道为什么这段代码有效。在任何版本的 C++ 标准中,标量流对象都无法与整数 或 到 nullptr_t
相媲美。话虽这么说,你的问题不是如何修复你找到的代码,而是如何绕过错误。 我不建议在生产代码中执行我将要在此处说的内容。这是一个 hack,它只是为了让像这样的不寻常的库工作而设计的。
==
运算符可以在任何 class 之外定义为独立函数。您正在使用的库将 std::ofstream
与 long int
进行比较。让我们使该比较有效。
bool operator==(const std::ofstream&, long int) {
return false;
}
现在您的代码可以编译了。但它可能 运行 不正确。您可以通过检查 std::ofstream
是否真实来尝试使比较更智能。
bool operator==(const std::ofstream& out, long int n) {
return (bool)out == (bool)n;
}
现在更聪明了。但这里没有灵丹妙药。您获得的代码 无法正常工作并且不是标准 C++,因此没有完全可靠的方法可以在不更改实际库代码的情况下使其正常工作。所以我的建议是分叉存储库并自己修复断行代码。
我的猜测是这个 (if(dFile==NULL){
) if 条件试图检查文件是否已成功打开以进行写入,如果是,则使用 c++ 中可用的函数 is_open
。所以只需将条件替换为if (dFile.is_open())
。这应该可以解决问题。
在 C++ 98 中,流曾经有一个 operator void*()
来检查流状态。当流处于错误状态时,它返回一个空指针。事实证明,这种隐式转换在奇怪的地方意外调用时会导致一些意想不到的结果。
因此在获得显式运算符的 C++11 中,它变成了 explicit operator bool()
。 returns true
表示状态良好,false
表示流处于失败状态。
作为explicit
它也只能用在需要bool
的地方。这从旧运算符中删除了大部分意外转换。
所以 if(dFile==NULL)
,测试流的非良好状态,现在写成 if (!dFile)
。
实际上,测试 if (dfile)
(良好状态)和 if (!dFile)
(非良好状态)一直有效。从来不需要与 NULL
进行比较,它只是在运算符返回 void*
.