On Wed, Oct 12, 2011 at 8:11 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Jorge Lodos Vigil wrote:
Robert Stewart wrote:
I created just such a temporary file class for use in our unit test library. It uses OS-specific APIs to create a temporary file which it destroys on destruction. Obviously, such a class must provide normal file operations to be useful, whereas scoped_file is merely concerned with removing the file upon scope exit.
I don't believe a temporary file class _must_ provide any file operation, it would be very useful by just ensuring that the created temporary file is unique and exposing its name.
If temporary_file creates the file but exposes no file operations, then one must call a pathname() function, close the temporary file in a way that doesn't delete it, open the pathname using another class (std::fstream, boost::filesystem::fstream, etc.), and then ensure that the other object is destroyed before the temporary_file instance removes the file (at least on Windows). That's hardly a pleasing interface.
A temporary_file class that includes file operations is, of course, beyond the current scope of Filesystem unless temporary_file were another variation of the file streams classes.
This is the problem that currently cannot be solved with boost::filesystem. If temporary files are not created together with the temporary path there is always a risk that the path is used between the time it was found and the file was created. To ensure _file_ uniqueness you must use functions like tmpfile.
It is enough to have a function that creates a zero-length, temporary file and returns its pathname. That probably fits better with Filesystem's design anyway. Such a function would have to implement a loop that calls unique_path(), tries to create a file with that pathname, and repeats some number of times until the creation succeeds. Then, it would close the file and return the pathname. That code is non-trivial and would be a helpful addition.
If you guys can come up with a good design for a temporary file feature, implement and test it, and provide at lease a sketch of some docs, I'd be happy to add it to the library. But I need to spend my time on other aspects of the library. One feature I've used a lot is the ability to not actually delete the file (or directory - I often need temporary directories). When I'm tracking down a bug it is often helpful to retain the file so it can be inspected. That also implies knowing the path to the file. --Beman