Boost logo

Boost :

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-19 09:51:14


From: Beman Dawes [mailto:bdawes_at_[hidden]]
>
> At 04:56 PM 3/18/2002, dylan_nicholson wrote:
>
> > The
> >first cut of the library can get by fine with just a 'remove' that
> >throws exceptions on all possible errors
>
> Yes, that is the plan for the basic remove operation.

I think the "basic" remove() should not throw an exception for the
equivalent of ENOENT. That is, if the postcondition is satisfied, then
remove() need not throw an exception, even if the file didn't exist when
called.

> >As for the temporary file case, there's actually a good argument for
> >a RAII-style "temporary file" and "temporary directory" class (I've
> >used them quite a bit myself). As it is I don't think
> there has been
> >a proprosal to support things like tmpnam etc.
>
> I'm also inclined to think temporary names (or unique names) will be
> needed.
>
> I had to provide similar functionality years ago, and found that a
> guaranteed unique name based on a hint was much more useful
> that names like
> temp0345.

I've done things like that myself. It is useful to get just a temporary
filename and it is useful to get a temporary file. When asking for a
temporary filename, at the time the name is generated, a file by that name
must not exist, though by the time the application tries to use it, another
process/thread could have created a file by that name. When creating a
temporary file, the function must try some number of times to generate a
file using a unique filename, throwing an exception if the retry limit was
exceeded.

There are many times when I don't care what the temporary file's name is. I
just need a file[name]. However, there are also times when I want to
associate the temporary files I create with a particular application or
process, so there must be a way to influence the filenames. The point is
that both facilities are useful: don't care and do care about the name.

As Dylan suggested, RAII is a good approach for the temporary files. I
suppose that means the objects hold fbufs or something like that in order to
make them useful to [io]fstream objects and still keep the files open.
Perhaps they could hold open FILE *'s and provide accessors for a FILE * or
an fbuf.

Rob
Susquehanna International Group, LLP
http://www.sig.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk