Invisible <voi### [at] devnull> wrote:
> 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?

> What I can't figure out is what happens if foo() is actually a function 
> somewhere in the OS kernel. Presumably in each version of the kernel, 
> the base address of this function is going to be different... so how the 
> hell does the linker know what it is?

  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.

  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.

> >> True... But I'm still wondering how VS does this in the absence of 
> >> header files.
> > 
> >   Does what?

> Figures out what parts of the contents of a source file should be 
> accessible from other files.

  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. (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).

> Like, if aux.c contains foo(), bar() and baz(), which of these should be 
> available from elsewhere? Normally if you only wanted foo() to be 
> public, you'd only put foo() in the header file. (And for God's sake 
> remember to update the header file when foo() changes its type signature!)

  Being in a header file is not what determines whether the function can
be called from the outside or not. In C, the keyword 'static' determines
that.

-- 
                                                          - Warp

Post a reply to this message

>> Couple that with a cryptic syntax 
> 
> Say, how's that Haskell parser coming along?

Yes, because how easy a grammer is for a machine to parse is *totally* 
related to how easy it is for the human mind to comprehend.

Go Google "natural language processing". ;-)

Post a reply to this message

>> 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

On 07/22/09 05:21, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> IME, programs written in C are almost always unreadable. But I'm biased. ;-)
>
>    Your problem is that you refuse to aknowledge readability even for examples
> which clearly are, probably because of some principle.

	Well, just because C is more readable than Haskell doesn't mean it's 
readable.<G>

	If David is still reading, I can sympathize with him being scared of 
OOP if he was introduced to it via C++ or Java. Constructors can be a 
pain in C++, along with other problems. I'd suggest some "simple" 
language like Python where the syntax won't get in the way of 
understanding the OO principles.

-- 
When the lion was given his courage, he promptly ate up the Wizard, 
Dorothy, the scarecrow and the tinman.

Post a reply to this message

On 07/22/09 04:13, David H. Burns wrote:
> I was told I was off topic in the programming group -- or maybe it's

	There's a newsgroup for discussing ideas about POV-Ray 4:

povray.pov4.discussion.general

-- 
When the lion was given his courage, he promptly ate up the Wizard, 
Dorothy, the scarecrow and the tinman.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> 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.

  Well, that is how an IDE works. You give it a bunch of source files and
it knows how to create 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.

  That's correct.

-- 
                                                          - Warp

Post a reply to this message

>>>> 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.
> 
>   Well, that is how an IDE works. You give it a bunch of source files and
> it knows how to create a runnable executable out of them.

Well, certainly you give it a bunch of files and it knows how to compile 
them. But do you want it to link them all into a single executable? Or 
maybe two seperate executables? Or perhaps you're trying to produce a 
DLL? Presumably you have to configure this somewhere...

>> This implies that an executable file contains some metadata in addition 
>> to the executable machine code itself.
> 
>   That's correct.

Interesting. I thought it was only object files that contain linker 
tables...

Mind you, having just said that... various programs have custom icons 
and so forth. That's definitely not executable code. Hmm...

[Now the old MS-DOS *.com files really *are* just bare machine code, 
always loaded at a specific machine address...]

Post a reply to this message

Invisible wrote:
> 1. How does it know which files depend on which other files?

Trivially, it compiles the file and sees which other files it opens during 
the compilation. With GCC, you can even give a command-line parameter to 
generate a makefile from the compilation. (-M or some such)

> 2. A header file is what defines what can be accessed from outside a 
> given source file. Without a header file, how do you determine what's 
> supposed to be public and what isn't?

No. You're thinking that header files are part of the language or something. 
It's just a convention.  If you're accessing something outside of the file 
you're compiling, you declare it "extern". It's convenient to put the 
"externs" in a separate files, but it isn't necessary.

> (C is a lot simpler, it's 
> just astonishingly easy to shoot yourself in the foot with it.)

Yes. Maybe you should try something intermediary first, like C# or Java or 
Pascal or some such.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

>> 2. A header file is what defines what can be accessed from outside a 
>> given source file. Without a header file, how do you determine what's 
>> supposed to be public and what isn't?
> 
> No. You're thinking that header files are part of the language or 
> something. It's just a convention.  If you're accessing something 
> outside of the file you're compiling, you declare it "extern". It's 
> convenient to put the "externs" in a separate files, but it isn't 
> necessary.

I see...

I know a header file can theoretically contain anything. But I always 
thought that the idea was to put only public things in a header file, 
because if it's not in the header file, other files can't know it exists 
so it can't be accessed.

>> (C is a lot simpler, it's just astonishingly easy to shoot yourself in 
>> the foot with it.)
> 
> Yes. Maybe you should try something intermediary first, like C# or Java 
> or Pascal or some such.

Java and Pascal I already have quite extensive experience with. 
(Although I imagine since the last time I touched Java the APIs have 
been changed *again*. Oh, and I hear they kludged in generics?) Both of 
these languages know the difference between a pointer and an array, however.

Post a reply to this message

Invisible wrote:
> True. But presumably if you #include a file that defines a function 
> prototype, you also need to compile and link whatever file it is that 
> contains the source code for that function?

Nope. Only if you actually call the function.  Don't confuse dependencies on 
source files with dependencies on library files.

> (Except for the OS header 
> files; I have literally *no clue* how that works...)

Exactly the same way, except the compiler by default knows where to look for 
those libraries.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message