I've tried just about everything.
Can anyone give me some help.

Recommended Answers

All 9 Replies

Steps

  • Open original file for input, in binary mode std::binary as second parameter
  • Open output file for writing in binary mode
  • Create an unsigned char array for i/o
  • In loop call ifstream's read() method to read , then write the buffer using ofstream's write() method, until end-of-file.
  • Close both files

Thank you!

Here's what I got...

#include <cstdlib>
#include <iostream>
#include <fstream>
using namespace std;

int main(int argc, char *argv[])
{
ifstream::pos_type size;
char * memblock;
    
    ifstream joe ("Hi.bmp",ios::binary);
    ofstream uld("Bye.bmp",ios::binary); 
    
    size = joe.tellg();
    
    memblock = new char [size];
    joe.seekg (0, ios::beg);
    
    joe.read (memblock, size);
        
    uld.write (memblock,size);
        
    system("PAUSE");
    return EXIT_SUCCESS;
}

?????

you have to seek to the end of the file before calling tellg(). When the file is opened the file pointer is at the beginning of the file, not the end.

I have a question regarding coping of files:-

Is there any difference between Ancient Dragon's style of coping each byte at a time by looping through till EOF and azjherben's style of coping in one shot? I mean to ask about efficiency and all.

I think azjherben's would be faster and more efficient.

Need comments on this.

Thanks,

Here is my uploader...

if (mgcheck == "upload"){
string bob;
bob = getcotz(rst);
string job;
job = "uploaz " + bob;

char *cotz = new char[strlen(job.c_str())];
strcpy(cotz,job.c_str());

sockClient.SendData(cotz);
}

Here is my downloader...

else if (commandz == "uploaz"){
                string asg = recMessage;
                string cuasg = asg.substr(7);
 cout<<"Downloading";

                               ofstream uld("Lol.bmp", ios::binary|ios::out); 
                                                uld.write(cuasg.c_str(),);
  cout<<"Downloaded\n";
                         }

Here is the getcotz function:

char * getcotz(string fnam)
{ 

ifstream::pos_type size;
char * memblock;
    
    ifstream joe (fnam.c_str(),ios::binary|ios::in);

    joe.seekg (0, ios::end);
    size = joe.tellg();
    
    memblock = new char [size];
    joe.seekg (0, ios::beg);
    
    joe.read (memblock, size);

return memblock;
}

I tried the basic example and that was okay.
But uploading/downloading won't work...

I have a question regarding coping of files:-

Is there any difference between Ancient Dragon's style of coping each byte at a time by looping through till EOF and azjherben's style of coping in one shot? I mean to ask about efficiency and all.

I think azjherben's would be faster and more efficient.

Need comments on this.

Thanks,

Copying everything in one shot is ok for small files that will easily fit in memory at one time. But will not work with huge files. I did not intend to suggest copying one byte at a time, but copying a buffer full, normally 255 bytes, at a time (depending on the sector size of the hard drive). Efficiency will depend on the operating system and how it handles buffered i/o. Some operating systems will not physically write to disk until its internal buffers are filled up. Similar with read requests -- the os might read a lot more data from the disk than requested in anticipation of another read request from the adjacent area (dick sector).

commented: Well explained +3

I tried the basic example and that was okay.
But uploading/downloading won't work...

What do you mean by uploading/downloading? Uploading what from where? Does that have anything to do with copying a file or is that a different problem ?

Copying everything in one shot is ok for small files that will easily fit in memory at one time. But will not work with huge files. I did not intend to suggest copying one byte at a time, but copying a buffer full, normally 255 bytes, at a time (depending on the sector size of the hard drive). Efficiency will depend on the operating system and how it handles buffered i/o. Some operating systems will not physically write to disk until its internal buffers are filled up. Similar with read requests -- the os might read a lot more data from the disk than requested in anticipation of another read request from the adjacent area (dick sector).

Thank you!! Really helpful.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.