hey guys.....i want some more help from you....i justwant to calculate the size of 17.mp3 in mb or kb......so what will i do ...count every int then calculate or there is an another way out.......
> I've malloced gigabyte size buffers many times with no problems
If you wanted this data in memory for a long time, then that would be fine.
But copying a 1GB file by allocating one large block of memory is basically a big waste of resources (and possibly even slower than you imagine).
For one thing, few operating systems will commit 1GB of REAL memory to a process which has only written to each page only once. Which means a large chunk of that memory you just loaded with file data is going straight back out to the swap file.
Then it comes back in from the swap file and out to the place where you wanted to save it.
It's also prone to random failure. One day you might be able to allocate enough space for a particular file. But maybe tomorrow, there is an extra process on the OS, or the file is just a little bit larger, and your attempt to allocate one stupidly large buffer returns NULL instead.
What's your error message to the user at this point?
"Sorry, unable to copy file due to ..."
Try this
No malloc/free issues, no swap file thrashing, works for files of any size.Code:unsigned char buf[BUFSIZ]; size_t n; while ( (n=fread(buf, 1, sizeof(buf), in ) > 0 ) { size_t r = fwrite( buf, 1, n, out ); if ( r != n ) { // some error message, probably no space left // use ferror break; } }
And don't play that "It's only a small MP3 file" crap, because you know some doofus will just look at that code and think "Hey, it worked for MP3, what about AVI files?".
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I agree with salem, reading the whole file does not always make faster.
The problem is that you gave him an example which may result in bad habits and severely affect his coding style. Think what can happen in the future if he works as a programmer in a big company. He may be involved in a large desktop application sold to thousands of customers worldwide.
Suddenly it will crash.
Do you want to be responsible for this?
Shame on you.
:o
Copying by reading byte by byte and reading all are two extremes that you should avoid. LOL
Doing something wrong years does not make it right.
May be your program always run fine on same machine, same platform, etc... you need to consider... these all.(environment that your code will run).
My laptop has only 1GB of memory. Do you know how much my system hangs when I allocate just 500MB with malloc()?
Tell ya what... in anything that got beyond my own hard disk, I would have --and always do-- include a lot more error checking. I was trying to give the OP a concept --an idea-- not redistributable code...
In any case, the point is made, and I agree a smaller buffer and a loop would have been better...
In future I will mark these things with "Provided to show concept only"
Yes I know the code is not important. but the concept in the code is not really a good one.
Edit: I think there's no point continuing discussion either.
Last edited by Bayint Naung; 05-30-2011 at 09:34 AM.