Question

我正在使用一个名为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要么不够，要么完全错误。是否可以选择在旧系统上编译或将代码更新为最新标准（我自己无法做到）？

Answer 1

我不知道为什么这段代码有效。在C ++标准的任何版本中，标量流对象都与整数或到nullptr_t相当。话虽如此，您的问题不是如何修复您已找到的代码，而是如何绕过错误。 我不建议在生产代码中执行我要说的内容。它是一个黑客攻击，而且它只是为了让这样一个不寻常的库工作而设计的。

==运算符可以在任何类之外定义，作为独立函数。您使用的库将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 ++ ，因此没有完全正确的方法可以在不更改实际库代码的情况下使其工作。所以我的建议是分叉存储库并自行修复破碎的代码。

Answer 2

我的猜测是这个（if(dFile==NULL){）如果条件试图检查文件是否成功打开进行写入，如果是这样你使用c ++中提供的函数is_open。所以只需用if (dFile.is_open())替换条件即可。这应该可以解决问题。

Answer 3

在C ++ 98中，流曾经有operator void*()来检查流状态。当流处于错误状态时，它返回空指针。事实证明，这种隐式转换在奇怪的地方意外调用时会导致一些意想不到的结果。

因此，在获得显式运算符的C ++ 11中，它变成了explicit operator bool()。这将返回true表示良好状态，并在流处于故障状态时返回false。

成为explicit它也只能用于需要bool的地方。这将从旧操作符中删除大多数意外转换。

所以if(dFile==NULL)，测试流的非良好状态，现在写成if (!dFile)。

实际上，测试if (dfile)（良好状态）和if (!dFile)（非良好状态）始终有效。从来没有要求与NULL进行比较，只是在操作员返回void*时才会有效。

Answer 4

在不知道其余代码的情况下，您可以尝试重新划分该行，例如：如果（！dFile）

看看接下来会发生什么。

如何完全绕过`错误：不匹配'operator =='`？

4 个答案: