Question

我正在使用C ++库，该库广泛使用如下构造：

FILE *out_file1, *out_file2 ... *out_fileN;

//for some output files, but not all:
out_file1 = fopen( filename, "w" )

//later
if( out_file1 ) fprintf( ... )
if( out_file2 ) fprintf( ... )

这似乎在OS X上的g ++下运行正常。但是当我在linux上运行它时，我得到了段错误。检查代码时，out_file通常初始化为非零值。

我尝试过添加

out_file = NULL

但这似乎没有帮助 - 事实上，根据调试器，它不会改变out_file的值。

任何人都可以提供帮助：

这是一种公认且合理的文件IO方式（即在条件语句中使用文件指针）

为什么指针的值没有设置为null？

如何将其设置为null？

只是要清楚 - 我正在尝试尽可能少地更改代码，因为我正在为其他人的库编写包装器。因此，即使一般结构是一种奇怪的做事方式，我宁愿找到一种在可能的情况下不会改变它的解决方法。

修改由于这似乎是一种合理的，如果过时的方式来做条件文件IO，我可以将我的问题的范围缩小到三分之二，即。

class IO
{
private:
    FILE* opFile

    IO()
    {
         //At this point, opFile == 0x40
         opFile = NULL; //At this point opFile is still 0x40
    }
}

很明显，如果它来自具有非null值的构造函数，则类似于：

if( opFile ) fprintf( ... )

会失败。但是如何使用非null值从构造函数中解脱出来呢？

如果它有帮助，这在OSX上的gcc下“按预期”工作，但在Ubuntu上不是g ++ - 4.3或g ++ 4.4。

Answer 1

您的问题出现在代码的其他地方，很可能是您提到的* printf调用？

向我们展示更多代码，或使用调试器查找崩溃的位置。

g++ -O0 -Wall -g mysource.cpp -o test
gdb ./test
(gdb) run argument1 argument2

另外，请查看valgrind以获取更多内存检查工具

valgrind ./test

$ 0.02

更新

添加-O0以避免将分析与正确的编译器优化结果混淆：）

Answer 2

在 C ++ 中，您应该使用iostreams，这将帮助您避免所有这些问题...

std::ifstream in ("some_file");

if (in)
{
  // do stuff with stream...
}

Answer 3

这是您程序中的实际代码吗？

FILE* out_file1, out_file2 ... out_fileN

然后只有out_file1是FILE*，其余只是FILE。这可以解释他们的“有趣的价值观”。

Answer 4

在C ++中，您应该使用std::fstream（或std::istream / std::ostream）来获取文件IO，除非您有充分的理由不这样做。然后你很可能没有这个问题，因为你可以这样写：

std::ifstream file("myfile.txt");

while(file) { // this checks for any error
    // do stuff with file
}

Answer 5

编译器可能正在优化您的代码。在将f_nn的返回值赋值为out_file之前，将out_file分配给NULL是没有意义的。编译器可能知道并且不打算分配NULL。

您可以在一行上定义和初始化值：

FILE* out_file = fopen( filename, "w" )

但是，这不会让你的问题消失。正如有人评论的那样，你可能会看到错误的代码，因为这似乎没有太大的错误。

您可以尝试创建一个只执行所需操作的最小应用程序，并在重新引入其余代码之前查看是否正常。

在C ++中使用文件句柄的条件

5 个答案:

更新