 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/22/09 05:21, Warp wrote:
> Invisible<voi### [at] dev null> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> 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?
If you want two separate executables, you create two separate projects.
(In most IDEs you can create multiple projects inside one single "solution",
as Visual Studio calls it.)
If you want to build a DLL, you tell it that in the project settings.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Neeum Zawan wrote:
I am still reading and enjoying.
David
> 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.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I see. So you still have to manually define what needs to be linked
> somehow?
Lets just say I'm working with source files right now where the line used to
compile the file takes up more than one screen of text in the editor.
> - You write foo.c that contains a function called foo().
OK. A function *definition*.
> - You write foo.h which simply states that a function called foo()
> exists somewhere.
A function *declaration*.
> - main.c does a #include "foo.h"
Which is exactly the same as if you had copied the text of foo.h into main.c.
> - When main.c is compiled, it produces main.o, which contains several
> references to a foo() that should exist somewhere, but we don't know
> where yet.
No. Only if main() actually calls foo().
> - The linker takes main.o and foo.o, and replaces every jump to foo()
> with a jump to an actual machine address. The resulting program is
> actually runnable.
Sort of. That's called "linking." Then there's "loading", which is when you
put it into memory and *again* adjust a bunch of addresses.
> What I can't figure out is what happens if foo() is actually a function
> somewhere in the OS kernel.
It isn't. The read() function in C, for example, is in the C runtime library
(glibc or uclibc on Linux). The linker always searches that library as part
of the linking process (unless you're doing something funky like compiling
the kernel). The read() function in that library is written in assembler
(because C is really not very useful for this sort of work) and that
assembler code copies items off the stack into machine registers and then
invokes an assembler instruction that causes the CPU to set certain flags in
the CPU registers that control permissions, change memory maps, and
eventually winds up branching to a particular address in memory which the
kernel has previously set to be a branch instruction to the code to handle
read(). So read() is normal, except it's in a library the compiler always
searches and contains assembly language.
> 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?
It doesn't. It executes a machine-code instruction that's essentially a
software interrupt. (That's why you see things like DOS functions being
described as "Int 21h" functions.)
It's an instruction that invokes an indirect branch.
> The way this works on the Amiga is that you can't just *call* an OS
> function.
There's no memory protection or kernel mode on AmigaOS. It can't be multiuser.
> 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.
Header files are 100% orthogonal to visibility. You're being confused by
convention.
If your program defines foo(), it's visible. I.e., if you write
int foo() { ... }
then foo is visible in any source file holding that text.
If you write
extern int foo();
then foo is visible in any source file holding that text, but if you invoke
it, you need to define it (see above) somewhere at link time.
That's your two choices.
When you actually call foo() from inside some other function, it has to be
visible. (Actually, the C standard says it gets a default declaration, but
nobody relies on that, because it was such a bad idea.)
> (And for God's sake
> remember to update the header file when foo() changes its type signature!)
And for God's sake, remember to include the header file where you invoke it.
It hasn't anything to do with header files. You could build a whole OS with
no header files. But if you changed the defintion of foo(), you'd have to
find every file with an "extern int foo()" and change it to "extern long
foo()", which is why people put them in include files.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
