Help to copy files in c++

**phantomotap** · 11-14-2008

Why not just be platform-agnostic about it?

Fixed (mostly):

Code:

bool copyfile(const std::string & source, const std::string & dest)
{
   std::ifstream in(source.c_str(), std::ios::binary | std::ios::in);
   if(!in)
   {
      return(false);
   }
   std::ofstream out(dest.c_str(), std::ios::binary | std::ios::out);
   if(!out)
   {
      return(false);
   }
   in.exceptions(std::ios::badbit);
   out.exceptions(std::ios::badbit);
   in >> std::noskipws;
   std::copy(std::istream_iterator<unsigned char>(in), std::istream_iterator<unsigned char>(), std::ostream_iterator<unsigned char>(out));
   return(true);
}

Soma

**brewbuck** · 11-14-2008

Originally Posted by phantomotap

Fixed (mostly):

Good catch on the stream constructors and exception masks.

As far as the char --> unsigned char change, I don't think it matters.

**phantomotap** · 11-14-2008

As far as the char --> unsigned char change, I don't think it matters.

*shrug*

I don't like the idea of using a type that may be distinct from its signed and unsigned variants. It doesn't make any sense.

Soma

**CornedBee** · 11-14-2008

You've got to admire the inefficiency of this approach.

**Elysia** · 11-14-2008

And that is why I always argue CLI tools should go away, and an API provided instead.
Oh, but there are APIs these tasks...

**CornedBee** · 11-14-2008

And that is why I always argue CLI tools should go away

Because someone might use system() to call them?

Hey, maybe we should do away with computers. Someone might use them to hack into another.

**brewbuck** · 11-14-2008

Originally Posted by CornedBee

You've got to admire the inefficiency of this approach.

I'm not sure it would be all that inefficient. Of course it's more efficient to copy larger blocks rather than bytes at a time, but as far as std::copy and the stream iterators are concerned, that should all optimize away into a loop which gets byte from the input and writes it to the output. Combine that with the buffering and I think it's not too bad. Not that I've benchmarked it.

**CornedBee** · 11-14-2008

Stream iterators go via the insertion/extraction operators. These have to construct a sentry object, which does all kinds of useless checks. They have to look for and obey stream state (bad, fail and eof bit). They have to look for and obey formatting settings (in particular setw()). They then call get()/put(), which repeats the state check. They then use the stream buffer to store the data. If the buffer is full, they flush/fill it and will have to check the stream state afterwards.
I doubt any compiler optimizes all the useless parts away, or even inlines the <</>> calls (which is a prerequisite for opimizing anything away).
In the course of this action, every byte is typically copied at least five times in memory, and that's assuming pretty good register-holding of the byte.

At least you should use streambuf iterators for this stuff.

I know, I know, copying is I/O-bound anyway. But I'm sure the OS copy routine has some optimizations there, too. Maybe there's a disk-to-disk copy command that the disk controller supports, and the data never even has to travel over the bus.

**brewbuck** · 11-14-2008

Eh, you're right. I checked both G++ 3.x (only thing I have around at the moment) and VC8 and the assembly code... sucks.

I still like how it looks. And we could create a raw byte I/O iterator, but I was just wasting time anyway.

**execute** · 11-14-2008

Did you have to pull out the std stuff?

CopyFile worked fine, and the person never said he was using linux

.

**Helgso** · 11-16-2008

How do you put files/folders inside a .exe?

**cpjust** · 11-16-2008

Originally Posted by Helgso

How do you put files/folders inside a .exe?

You mean like a self extracting ZIP file?

**Helgso** · 11-17-2008

Yah, when executed, it would copy files included in itself to a desired location.

**Angus** · 11-17-2008

Originally Posted by cpjust

You mean like a self extracting ZIP file?

I made a miniproject that did that once. One executable in the project, called "Sourcize", was a program that serialized the subject file into a set of C-style arrays (it had to be a set of them since the compiler I was using puts a cap on the number of elements an array can have) as source code, then another executable that used that source code, which is setup to write the arrays back to a file.
I'd give you the project, but it seems I can't attach zip files here. What I could do is give you the source code for the array structure.
The file is in the global g_arrays. Arrays.cpp is an abstraction, btw, and NOT legal C++, rather than the 4Mb file it was before I pruned it for you.

**EVOEx** · 11-17-2008

Originally Posted by brewbuck

Eh, you're right. I checked both G++ 3.x (only thing I have around at the moment) and VC8 and the assembly code... sucks.

I still like how it looks. And we could create a raw byte I/O iterator, but I was just wasting time anyway.

Wouldn't this be valid and faster:

Code: