>> I see. So you still have to manually define what needs to be linked somehow?
> 
>   How else is the compiler going to know which files are your source files?
> By reading your mind?

Well, that's what I was puzzled by, yes. You guys seemed to be 
suggesting that you just give VS a bunch of files and it somehow "knows" 
how to produce a runnable executable out of them.

>   That's what dynamic linking is all about. That's why they are called
> "dynamically linked libraries". The OS performs runtime linking when the
> program is launched: It goes through the program and sets jump addresses
> to their proper values.

This implies that an executable file contains some metadata in addition 
to the executable machine code itself.

>   And if the program uses a direct system call, it doesn't jump to some
> address. It tells the OS "I want to make this system call" and the OS then
> jumps there. The compiler (or more precisely, the system library the compiler
> is using) knows how to tell the OS that.

I see. (I think!)

>   In C every global function which is not marked with the keyword 'static'
> is accessible from anywhere. A function marked with 'static' is only
> accessible from that same source file but not from anywhere else.

Interesting. I never knew that...

Well, in that case it should be pretty simple.

> (Yes,
> reusing the keyword 'static' for this purpose is a kludge in the original
> C specification.)
> 
>   In C++ nameless namespaces are a cleaner way to achieve the same thing
> (and then of course there exist completely different mechanics for class
> member functions, which can be public or private).

Yes, yes, and yes. ;-)

Post a reply to this message