And people wonder why I have him on my ignore list...Originally Posted by MWAAAHAAA
And people wonder why I have him on my ignore list...
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.......
And I'm such a likable fellow...
iMalc: Your compiler doesn't accept misspellings and bad syntax, so why should we?
justin777: I have no idea what you are talking about sorry, I use a laptop and there is no ascii eject or something
Have a look at CommonTater's first post for a possible approach.
iMalc: Your compiler doesn't accept misspellings and bad syntax, so why should we?
justin777: I have no idea what you are talking about sorry, I use a laptop and there is no ascii eject or something
Take a look at the code sample I posted... there's a very easy way to do it, in there.
Once you have the file size divide by 1024 for Kilobytes or 1048576 for Megs.
Last edited by CommonTater; 05-29-2011 at 05:41 PM.
> 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.
Ok... I see your point and I've done things that way too... but with decent sized buffers ... 256k or such... not character by character...
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
(SIGH!) Salem at least had the decency to explain ....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.
I guess I shouldn't mention that I have programs out there that open 800meg to 1gb files, work on them and then write them back out, all in one big blob... And have been doing that for YEARS without problems...
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...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()?
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.
It's fine to continue far as I'm concerned... but maybe we should get back to the OP and his problem...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.
