On 24/04/13 21:58, ballsystemlord wrote: > The idea of reading from the file with several threads was because I thought > that one thread might not be able to keep up with the demands of several > (several i.e. an amount dependent on the amount of CPU cores.) Of several what? If you only want to copy a file, your program will be I/O bound, and using several threads on multiple cores won't help. Those threads will be simply sleeping until the partial file contents finishes being transfered into/from memory. The IO scheduler may take slightly different decisions, but the final timing should be the same. If you were doing something cpu-intensive with those contents (such as ciphering them before writing into the new file, or computing hashes), using multiple threads may help. But not on this case. And I don't think you're prepared for thread programming yet. > Yes it may not be specifically about how to use GCC but GCC is what I'm > using and I'm not, at least at present, intending to try for cross platform > compatibility, therefore my options on how to go about reading the file are > determined by the functions available from GCC so I though it a more GCC > type question. GCC does not provide any function for reading files. This may seem surprising for you when coming from an interpreted language background, but there are no native/special methods for that. They are all normal C functions, with the downmost coded in assembler. (The C standard then defines some function names, and what they should do, but those are provided by the C library, not by the compiler) > Yes, I know, it's a lot for a beginner to C to be concerned with, but when > you have a great idea and implement a prototype with python3 and it works > (though rather limitedly)... it's one of those "I must learn to program this > really cool thing myself." situations (and to achieve the necessary speed > you need it in C.) If you are just copying a file, that won't be faster in C than in python (well, unless python adds some silly intermediate step). Because there's almost no code to run. > When I said "How do I write part of an int into my file" I meant that the > binary data is much smaller then text data and that I would need to write > into the file some numbers smaller than an int or even possibly a short int > and it would waste space to have thee unused bytes out of every four. It depends. Can those 4 bytes be needed, or will the contents always be smaller than 256 bytes? And is "wasting" those bytes really important for the final file? > But let's back up a second I'm getting ahead of myself. First I might say > that I am assuming that when writing in binary mode I am sending the write > function ints or similar and it's writing out 1s and 0s to the file > corresponding to the value of the int (or similar.) The same goes for > calling the read function which returns x amount of bytes in an int (or > similar,) into which is stored a number not 1s and 0s. Of course I can work > with 1s and 0s if that is what it gives me but I didn't think it would > (despite the fact that I've read hundreds of pages of how to program in C > the endianness nor the output of low level reading of binary files has been > discussed -- at all.) The functions are read/write and fread/fwrite if using stdio. As you can see, you are really working with buffer, it doesn't care if the variables where you read/store the data are char buffers, ints or floats (although interpretation will then differ, of course). I think I gave you a few keywords in my previous mail which should help you discover the issues you may face with your files. Finally, you should really get a C tutorial. Any good one should explain how to read and write files.
