Boost logo

Boost :

From: Dylan Trotter (trotterdylan_at_[hidden])
Date: 2005-09-08 17:02:02

After I read the original Post I became interested in the problem as
well. The realization that I came to is that there are more objects
involved than just a istreams and ostreams. If you were to create an
ostream that deleted the file on destruction, you'd find it to be
useless since you wrote some data, but have no way whatsoever of
retrieving it again. Coversely, opening a temporary istream would serve
no purpose, since it would obviously contain no data.

One possible solution, I felt was to have a sort of handle to the file.
For example:

class temp_file
     temp_file(const path &root) { /* create file in root */ }
     ~temp_file() { /* delete the file */ }
     const path &get_path() const { return path_; }

Then any i/ostreams that use the file hold a shared_ptr to it. The
lifetime of the temp_file is arbitrary and will exist only so long as
some stream is holding its pointer. So add:

typedef shared_ptr<temp_file> temp_file_ptr;

class temp_ofstream
     temp_ofstream(temp_file_ptr tempFile) : tempFile_(tempFile) { }
     temp_ofstream(const path &root) : tempFile_(new temp_file(root) { }

     temp_file_ptr tempFile_;

Actually, the implementation I came up with used a stream_buffer derived
class, but the effect is the same. To share the temp_file between
ostreams and istreams, do this:

temp_file_ptr file(new temp_file(""));
{ /* some scope */
     temp_ofstream out(file);
     /* do stuff with out */
{ /* some other scope */
     temp_ifstream in(file);
     /* do stuff with in */

However, there are problems with this layout. In particular, there's
race conditions with the actual filesystem object. Also, there needs to
be some kind of access control to the file supplied by the temp_file
object so you don't attempt to open a reader while you're writer or
vice-versa. In any case, just some preliminary thoughts.


Beman Dawes wrote:
> "Tomek" <at_at_[hidden]> wrote in message
>>Can you add to boost::filesystem namespace class for temporary files
>>which will remove file on object destruction ?
>>I prepared same sample code :
>>If you say that this is ok, I will write it using boost library and
>>also working on win32.
> I'm definitely interested, although the specification is of more interest
> than the actual code. I'm particularly interested in resolving any
> differences between POSIX and Windows, and avoiding security issues.
> It is a bit surprising that this is the first request I can recall for a
> temporary file facility. Seems like a natural addition.
> --Beman
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at