Boost logo

Boost :

From: Dylan Nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-19 17:28:33


 --- Aaron Brashears <gila_at_[hidden]> wrote: > In my tests, I've found a
combination of stat, mmap (there's a similar
> win32 api), and memcpy to be the fastest implementation available. I
> don't have any benchmarks available but it also stands to reason that
> handing the file copy routine over to the kernal will yield the best
> possible results for a general purpose file copy.
>
> Given that your astoundingly simple implementation is so, well,
> simple, it hardly seems to warrent inclusion as a file copy routine
> and should just be one of the many tricks in your bag.
>
Well not really, because my implementation has no error handling worth speaking
of :o) And unfortunately if you use fstreams there is very little error
information you *can* get. If you fail to open the either file, you can't tell
whether a) the (input) file doesn't exist b) the directory doesn't exist c) you
don't have permission d) the file is locked by another application e) the
device is not ready etc .etc. If you fail to actually perform the copy, you
can't tell whether a) the device failed b) the filesystem was corrupt c) the
disk was full etc. etc.
So given this my implementation is basically useless unless you know for a fact
that the implementation fstream uses fopen and you can safely query errno for
the error (the 1996 working draft states that fstream::open should use fopen,
but I'm not sure whether that really is a requirement honoured by all
implementations). Even if you could use errno, you obviously need to write
some code to trap these errors somehow:

void copy_file(const char* src, const char* dest)
{
 std::ifstream ifs(src);
 if (!ifs)
   throw_errno_error(src);
 std::ofstream ofs(dest)
 if (!ifs)
   throw_errno_error(dest);
 if (!(ofs << ifs.rdbuf()))
   throw_errno_error();
}

Dylan

http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.


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