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

Dani AI

Generated

Short, practical follow-ups based on the code and replies below.

The safe, general rule: treat bitmaps (and any non-text file) as binary data end-to-end. That means open streams with ios::binary, never rely on C-style null-termination for payloads, and avoid allocating a raw buffer and returning a raw char* without also returning its length. was right to recommend buffered I/O for robustness; 's uploader/downloader show the common socket pitfall — sending binary as if it were a C-string and not sending the length first — which will truncate at a 0 byte.

A robust local-copy pattern (does not require knowing file size up front):

#include <fstream>
#include <vector>

bool copyFile(const std::string &src, const std::string &dst) {
    std::ifstream in(src, std::ios::binary);
    if (!in) return false;
    std::ofstream out(dst, std::ios::binary);
    if (!out) return false;
    std::vector<char> buf(64 * 1024); // 64 KiB buffer
    while (in) {
        in.read(buf.data(), buf.size());
        out.write(buf.data(), in.gcount());
    }
    return out.good();
}

For network transfer: prefix the raw bytes with a fixed-size length (e.g. 4- or 8-byte integer in network byte order), then send exactly that many bytes. On receive, first read the length, then loop until you have read length bytes into a std::vector<char> and write that buffer to disk with a single write(buffer.data(), length) call.

Quick troubleshooting checklist: verify streams opened successfully; check in.gcount() after reads; do not use strcpy/c_str() for binary blobs; free any new[] or, better, use std::vector/std::string for RAII; and ensure your socket layer transmits/receives the full byte count (use looped send/recv helpers). This resolves the uploader/downloader problems shown above and scales safely to large files.

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.