QTemporaryFile: close method
-
I need to create a temporary file with a unique name. But I don't need to open this file within my Qt app, instead I need to pass the filename as an argument for QProcess.
To get the filename I need to open the QTemporaryFile. It's not a big deal... I might open, get the filename, close and call QProcess.But according to the documentation:
doc.qt.io/qt-5.6/qtemporaryfile.html
Reopening a QTemporaryFile after calling close() is safe. For as long as the QTemporaryFile object itself is not destroyed, the unique temporary file will exist and be kept open internally by QTemporaryFile.
I'm not sure about: "will exist and be kept open". Does that mean the file is still open even after calling close() ?
Is it safe to pass the filename to other applications which will use it to write data? -
Hi
Do you want to use as a filename generator?
It seems the file is first removed when deleted
http://doc.qt.io/qt-5.6/qtemporaryfile.html#autoRemove -
Do you want to use as a filename generator?
Exactly!
It seems the file is first removed when deleted http://doc.qt.io/qt-5.6/qtemporaryfile.html#autoRemove
When the object is deleted, not when the file is closed. See also:
http://doc.qt.io/qt-5.6/qtemporaryfile.html#dtor.QTemporaryFile
-
So in theory, you should be able to use the filename if you call
remove. OR if you simply delete it. -
@mrjj
I checked into the source code:bool QTemporaryFileEngine::close() { // Don't close the file, just seek to the front. seek(0); setError(QFile::UnspecifiedError, QString()); return true; }
Thuse, closing the file does not close it. Great.
I guess it's quite safe to generate the filename, destroy the object and immediately use that file name.
Because I don't need a lot of concurrent files I bet I won't receive the same filename in two consequent calls! -
but try the
http://doc.qt.io/qt-5.6/qfile.html#remove
That is what AutoRemove calls on destruction.
Doc says. -
@Mark81
Perhaps you should consider just using the STL, or rather the standard C library? For example std::tmpnam would be a good candidate, wouldn't it?