this is largely dependent on what linker you are using.
I disagree. It's got nothing at all to do with the linker. The linker doesn't know what a cpp and a h file is. The linker gets object files. Object files are already compiled. By the time the linker gets them, the extension name on the original text file is history and utterly irrelevant.
Commonly, header files are intended to be included into cpp files, but that's just convention. I could rename all my cpp files *.h, and all my *.h files *.cpp, or even rename them all *.randomExtension, and I'd still be able to compile and link the whole thing and produce exactly the same output program.
@ jumper007: Actually, I am that idiot: http://www.microsoft.com/licensing/software-assurance/windows-virtualization.aspx and apparently so is Mr Gates. I'm not a programmer, I'm a Sys Admin so I'm well aware of the licensing restrictions and allowences in the Microsoft EULA. I don't care if your English isn't that good, my English is terrible and it's the only language I speak!
@ Moschops: I thought it was the linker, but I can except that I'm wrong about which component does this (can you tell I use an IDE?). Code that is not used is optimized out, this includes functions that are not called at the time they are considered for inclusion within the executable (This is why I thought linker by the way). There was an article linked on Reddit a week or two ago that can explain it better then I can. If I dig it up can I PM it to you? Maybe I misunderstood some part of it but it seemed to make perfect sense to me.
I'm always happy to learn; I suspect that it said something along the lines of header files being discarded after they are #include ed.
This is true, but the cpp files are also discarded! The preprocessor uses cpp and h (and whatever else you feed it) files to build a new text file (which may well exist only in memory) that gets compiled. So long as that new text file is valid C++, all is fine, so you could put whatever C++ code you like in whatever combination of cpp and h and other files that you like, and as long as the compiler is handed a single text file (which may exist only in memory) that conforms to C++, it will turn it into a single object file for the linker.
I have in the past even fed the compiler directly from the command line without bothering with files at all, so it doesn't even need to be a file. :)
I have a question a bit off top here, but I know there's command-line programs (ie vim) which somewhat take control and manipulate the screen. I was wondering how they do this, is there a way to get access to the console buffer and change it's contents?
@ xerzi: That is actually the most on topic post since about the fourth one in this thread. The article that Duoas wrote\linked explains how to do this in the Windows section. Since modern Operating Systems do not allow you to directly interface with hardware you have to ask the OS for an interface to it, in that case it's the CONSOLE_SCREEN_BUFFER_INFO object. You interface with the console buffer using the API calls Duoas mentions in that article.
If you still need help on the clear screen command (as I didn't bother reading half the replies for this topic), I have an alternative: system("cls");
It works on my computer. I am using a 64-bit computer running Windows 7.