 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> This is similar to Java, although it is
> not platform independent (there is a platform independent open source
> version, called Mono, which is able to execute many .Net applications).
Actually, the CIL is indeed platform independent. What isn't is a large
number of windowing libraries and a few others that are per-OS, primarily
because you *can* get to some low-level stuff. There's virtually nothing in
the definition of the libraries or language that would be difficult (as
opposed to tedious) to implement on other OSes. Of course, if you do things
like inspect the Windows message pump, or you query the X server's WM
properties, you're going to have unportable code. A Windows service is going
to have different wrappers than a Linux service, because the two have
fundamentally different operational mechanisms. *That* is where the
non-portability bits come from. Well, that and that it hasn't been ported
too much yet.
> There are other technologies and features, of course, mostly aimed at
> interoperability of various system components (for instance, LINQ, which
> allows SQL-type queries from languages such as C# and VB).
There's also a tremendous focus on being able to use different parts of the
systems from different vendors. The whole bit of managing "components" is
that. So if you don't want to write it and it doesn't come with, chances are
good you can buy it already built for you.
--
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 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?
Yes. That's what the separate "projects" in one "solution" are, in VS.
> Or perhaps you're trying to produce a
> DLL? Presumably you have to configure this somewhere...
Sure. You set flags on the project properties pages.
> Interesting. I thought it was only object files that contain linker
> tables...
Depends on the OS and CPU. For example, on CP/M, you're right. The binary
.COM file is just bytes of machine code that load at 0x100, and the OS jumps
to 0x100 when it starts. That's responsible for setting up the stack (based
on an address left in global memory) and parsing the command line (at 0x80).
On even simple UNIXes, you have things in the headers to set up how big the
stack is, how big the "zero out this memory space" area is, and which
addresses have to have the start address where you loaded the executable
added. Any OS taking advantage of memory protection is going to have
metadata in the executable format.
> Mind you, having just said that... various programs have custom icons
> and so forth. That's definitely not executable code. Hmm...
Yep, that too.
> [Now the old MS-DOS *.com files really *are* just bare machine code,
> always loaded at a specific machine address...]
Yes, left over from CP/M.
--
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 wrote:
> 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.
No, it's so that there's only one place to change it when you change it. The
same reason you'd use an "include" in any other language or document or
whatever.
If it's not declared, you can't easily use it from outside where it's
defined. One declares it in a header file so one doesn't have to type it out
all the time or risk getting the declaration wrong.
However, sometimes when I'm debugging stuff that's just breaking deep in the
bowels of someone else's program, I'll do something like
{ extern int write(int,char*,int); write(1,"#1\n",3); }
just to put in a debugging line to tell me whether it crashed before
or after that point, which prevents me from having to #include the
right pile of header files to declare write() properly.
> 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.
True. C doesn't have arrays, really. At least, none with actual names.
So you have a lot of experience with Java, and you find *C's* syntax unwieldy?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> True. C doesn't have arrays, really. At least, none with actual names.
Actually C *does* have arrays. For example, this is an array:
int table[10];
Here 'table' is *not* a pointer to a memory location containing space
for 10 ints. 'table' is an array of 10 ints. While it behaves a lot like
a pointer (and is implicitly cast to an int* when necessary), there are
significant differences compared to a pointer. For instance, sizeof(table)
is not the same as sizeof(int*). Also, you can't make 'table' "point" to
somewhere else (because it's not a pointer).
These are stack-allocated arrays. It is also possible to create
heap-allocated arrays, although not directly. You have to enclose it
inside a struct, like this:
struct ArrayContainer
{
int table[10];
};
Here 'table' is also *not* a pointer, it's an array. Now you can allocate
instances of that struct with malloc() and you will effectively have a
heap-allocated array.
(Granted, C arrays are a bit rigid and non-dynamic, but they are still
arrays by any definition.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> For instance, sizeof(table) is not the same as sizeof(int*).
Yes, OK.
> Also, you can't make 'table' "point" to
> somewhere else (because it's not a pointer).
I thought "table" was essentially a constant pointer to the first element. I
forgot about the sizeof() bit. I.e., that "int table[10]" made table be a
constant pointer to the first element of an anonymous block ten integers in
size.
> Here 'table' is also *not* a pointer, it's an array. Now you can allocate
> instances of that struct with malloc() and you will effectively have a
> heap-allocated array.
int* table = malloc(10*sizeof(int));
creates an anonymous array, then sets "table" as a pointer to the start of
it. So you can have heap-allocated arrays, you just can't give them names. :-)
Now we're picking nits, tho. You're right, C does have arrays.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> int* table = malloc(10*sizeof(int));
> creates an anonymous array, then sets "table" as a pointer to the start of
> it. So you can have heap-allocated arrays, you just can't give them names. :-)
The other difference is that there's no way of retrieving the size of that
"array".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-7-2009 10:39, Invisible wrote:
> clipka wrote:
>
>> Once you've embraced the OO paradigms, you'll no longer wonder whether
>> it's a
>> step back or sideways - you'll know that it's a step forward.
>
> This is where I mutter something about functional programming being the
> future, and everybody agrees with me...
Nah, it was a long tome ago when these were the future (roughly between
'54 and '58).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
