Question

我有一个C ++程序，它使用ofstream创建一个输出文件“A”。然后，一些使用_iobuf打开文件的旧C代码读取此文件。遗留代码然后使用_iobuf创建自己的输出文件“B”，然后C ++程序使用ifstream读取该文件。这个序列被多次迭代，每次迭代都有相同的A和B文件名。

有时，C ++程序无法打开输出文件A进行写入，在成功之前我必须多次尝试。这种情况不确定地发生，并且可能在一千次迭代中发生一次。请注意，C程序永远不必等待打开其输入或输出文件，C ++程序也不必等待打开其输入文件。这种非正式观察基于数十万次迭代。

我想知道这是否与在同一个程序中混合ofstream和_iobuf有关？ C ++代码和C代码都链接到同一个程序中。遗留的C代码在技术上是C ++代码，但是以类似C的方式编写。有什么我可以做的，以消除等待打开ofstream文件？如果我可以避免遗留代码，我不想更改遗留代码。

伪代码（未编译）：

void someObject::someMethod()
{
    for (int count = 0; count < someLimit; ++count)
    {
        newerObject::firstMethod();
        olderObject::secondMethod();
        newerObject::thirdMethod();
    }
}

void newerObject::firstMethod()
{
    // do some processing first

    // then write the results of the processing to a file
    ofstream A;
    A.open("A", ofstream::out); // this sometimes must be tried multiple times
    // write data to file A
    A.close();
}

void olderObject::secondMethod()
{
    FILE* f;
    f = fopen("A", "rt"); // this always works the first time
    // read data from file A
    fclose(f);

    // do some processing

    f = fopen("B", "w");
    // write data to file B
    fclose(f);
}

void newerObject::thirdMethod()
{
    ifstream B;
    B.open("B"); // this always works the first time
    // read data from file B
    B.close();

    // do some processing
}

目前，作为一种解决方法，我将ofstream :: open放在do-while循环中。我很想摆脱这种尴尬。提前感谢您提供任何建议。

Answer 1

首先，问题几乎肯定不是使用不同的方法来访问文件：在引擎盖下，C和C ++ I / O函数使用相同的系统I / O工具。你好像在使用Windows（在其他系统上文件通常可以同时打开多次）而且我对系统知之甚少，但我怀疑文件系统还没有更新，以反映文件关闭时你试着打开它。这可能与“t”开放标志有关：我不知道这是什么。

在UNIX上，您可以强制I / O操作等待磁盘上的实际更改完成。这样的事情可以帮助避免这个问题，但是操作变得非常缓慢的成本很高。在UNIX上，一种方法是在文件成功打开时吹走文件系统条目（毕竟，此时它的名称不再使用）：

if (FILE* fp = fopen("file", "r")) {
    remove("file");
    // do processing
}

但是，如果我在Windows上正确回忆，您既不能删除文件也不能重命名。就个人而言，在解决问题时，我将按如下方式进行：

确定无法打开文件的情况，例如保持文件打开并尝试打开它。这主要是为了创建一个可以重现问题的设置，以便您以后确认确实找到了解决方案。
一旦我找到了重现问题的方法，我可能更好地了解实际的根本原因，并可能谷歌搜索会有所帮助。在任何情况下，这都是研究根本原因的地方。
一旦理解了原因，希望很容易设计出一个解决方案。如果没有，在其下多次打开文件是成功的，这可能是正确的解决方案。

ofstream :: open的延迟，可能是由于与_iobuf的混合？

1 个答案: