>> Oh, I have a far bigger "problem" than that: C is the number one 
>> language requested in job adverts. :-(
> 
>   I feel your pain because I hate C (but for different reasons than you).

It's very popular for "kernel-level development" for some reason.

(Of course, there are still plenty of people doing web development, who 
consequently want Java / Ruby / PHP / ASP / Python / whatever.)

>   Your problem is that you project your C prejudices onto C++ as well,
> and simply refuse to learn the tools C++ offers to make your life easier.

FWIW, it seems C++ has fixed some of the stuff I disliked about C. 
(Although I'm told almost every valid C program is also a valid C++ 
program, so nobody's forcing you to actually make use of these 
improvements...) It still has the problem of being inherantly designed 
to be unsafe, and being very low-level.

I guess it's just a question of motivation. If it weren't for the fact 
that everybody wants C / C++ programmers, I wouldn't even consider 
wasting my time learning it. It's highly unsuited to the kind of 
programs I write. But since everybody wants to use it... well maybe I 
could spend a few months trying to write a working C++ program. But I'm 
up against whizzkids who have been using nothing but C++ since they were 
9 years old. I have to feel I don't really stand a chance here...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> 1. How does it know which files depend on which other files?

  If you write an #include line, you create a dependency to that file.
It's that simple.

  (In C and C++ there's no difference between source files and header files.
They are just files containing code. You can include anything in anything
else. The compiler (nor the IDE) make any distinction. An automated dependency
tracker simply looks for #included files and creates dependencies based on
that.)

> 2. A header file is what defines what can be accessed from outside a 
> given source file.

  That's actually just a programming convention. As said, the compiler makes
no distinction between "header" files and "source" files. They are just all
the same.

  (Ok, some IDEs support so-called "precompiled headers", but even in those
the distinction is more a question of convention than anything technical.)

> Without a header file, how do you determine what's 
> supposed to be public and what isn't?

  A header file doesn't really determine what is "public" and what isn't.
It's just a convenience technique. It's easier to put declarations in a
common file and then simply #include that file than to have to write the
declarations in all source files which need them.

-- 
                                                          - Warp

Post a reply to this message

>> 1. How does it know which files depend on which other files?
> 
>   If you write an #include line, you create a dependency to that file.
> It's that simple.

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? (Except for the OS header 
files; I have literally *no clue* how that works...)

>   In C and C++ there's no difference between source files and header files.
> They are just files containing code.

>   A header file doesn't really determine what is "public" and what isn't.
> It's just a convenience technique. It's easier to put declarations in a
> common file and then simply #include that file than to have to write the
> declarations in all source files which need them.

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> Oh, I have a far bigger "problem" than that: C is the number one 
> >> language requested in job adverts. :-(
> > 
> >   I feel your pain because I hate C (but for different reasons than you).

> It's very popular for "kernel-level development" for some reason.

  C is popular for kernels and device drivers because the machine code
a C compiler generates is simple, straightforward and predictable. After
all, C is a rather thin wrapper around assembly. Also things like type name
mangling in C object files is relatively simple and de-facto standardized,
which makes it easier to write dynamic code loaders and such.

  Kernel development is almost as close to hardware programming as possible,
so the farther away from hardware-level programming you get, the more problems
you may encounter when things don't work as they should. Also many things
designed to aid in high-level programming, such as garbage collection, may
only get in the way in such low-level programming as an OS kernel or a device
driver.

-- 
                                                          - Warp

Post a reply to this message

> Now that's interesting.
>
> 1. How does it know which files depend on which other files?

It looks inside the files to see which other ones you have #include'd.

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

The stuff in a header file is just as valid in a source file, so just put it 
there.  IN fact instead of doing a #include you could just copy and paste 
that file and put it there instead.  Just like #include in POV.

> To use Haskell, you need to learn something like half a dozen basic 
> principles. After that it's just figuring out "OK, how the hell do I 
> perform task X?" Learning C++ it just seems like learning feature after 
> feature after feature, seemingly without end.

It's not like you need to know the whole of C++ (or even most of it) to 
write even quite complicated programs.

Post a reply to this message

scott wrote:

> It's not like you need to know the whole of C++ (or even most of it) to 
> write even quite complicated programs.

You do, however, need to know rather a lot before you can get started...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> 1. How does it know which files depend on which other files?
> > 
> >   If you write an #include line, you create a dependency to that file.
> > It's that simple.

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

  Of course you have to add all the source files to the project. The IDE
then compiles and links them.

  The dependencies are not for deciding what should be compiled and linked
into the final executable, or how the compilation should be done. The
dependencies exist simply to make compilation faster when changes are done
to the source files. If you have a 10-million lines-of-code program and
you modify one line, you don't want to re-compile everything. You only want
to re-compile the minimum amount necessary to get the updated executable.
That's what dependencies are for. This is all done automatically by the IDE
(or makefile).

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

  System library implementations have already been pre-compiled and come
with the system (or the compiler in some cases). Often they are dynamically
loadable, but you can link them statically to your executable if you want.

  Dependencies to most system libraries are automatically added to the
program by the compiler without you having to do anything about it. When
the dependency is not there by default, you simply have to specify which
system library you want to use in your IDE or by telling the compiler
(in the Unix side that would be those -l command-line parameters).

  To put it in simple terms: In the Windows side that's where a program
depending on a DLL file comes from. A DLL is simply a precompiled library
(which the OS loads dynamically when a program needs it).

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

  Does what?

-- 
                                                          - Warp

Post a reply to this message

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

The IDE has a list of source files in the project.

Post a reply to this message

>> 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?
> 
>   The dependencies are not for deciding what should be compiled and linked
> into the final executable, or how the compilation should be done. The
> dependencies exist simply to make compilation faster when changes are done
> to the source files. If you have a 10-million lines-of-code program and
> you modify one line, you don't want to re-compile everything. You only want
> to re-compile the minimum amount necessary to get the updated executable.
> That's what dependencies are for. This is all done automatically by the IDE
> (or makefile).

I see. So you still have to manually define what needs to be linked somehow?

>> (Except for the OS header 
>> files; I have literally *no clue* how that works...)
> 
>   System library implementations have already been pre-compiled and come
> with the system (or the compiler in some cases). Often they are dynamically
> loadable, but you can link them statically to your executable if you want.
> 
>   Dependencies to most system libraries are automatically added to the
> program by the compiler without you having to do anything about it. When
> the dependency is not there by default, you simply have to specify which
> system library you want to use in your IDE or by telling the compiler
> (in the Unix side that would be those -l command-line parameters).
> 
>   To put it in simple terms: In the Windows side that's where a program
> depending on a DLL file comes from. A DLL is simply a precompiled library
> (which the OS loads dynamically when a program needs it).

As I understand it (i.e., probably wrong), it works something like this:

- You write foo.c that contains a function called foo().

- You write foo.h which simply states that a function called foo() 
exists somewhere.

- main.c does a #include "foo.h"

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

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

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?

The way this works on the Amiga is that you can't just *call* an OS 
function. First you have to look up its base address in a table. 
Basically, memory address 0x00000004 contains a pointer to a table. 
Every OS function has a unique ID which is an offset into this table, 
which enables you to lookup the function's base pointer. And then you 
can jump to it. All of which takes about two-dozen assembly 
instructions... I have literally no idea how the hell you'd do it from C 
though.

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

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

Post a reply to this message

Invisible wrote:
> Couple that with a cryptic syntax 

Say, how's that Haskell parser coming along?

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

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

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

On 22-7-2009 1:26, David H. Burns wrote:
> andrel wrote:
> 
>> That you see your smiley does not mean everybody else will.
> 
> Thanks. Did you see it? I did when I read my own post. I don't think it 
> shows up in the text in
> my "sent" file. These matters get complicated.
> :) (smiley ?)
> 

I do. In your post, not when replying :) , neither yours nor mine.
The point I tried to make earlier is that it depends on the mail reader 
of the person *reading*. You don't have an influence on it. You type a 
colon followed by a bracket, that is what you sent and what is supported 
by NNTP. After that somebody is trying to cleverly replace them by 
rotated smileys, which is OK as long as they get it right :/
IIRC they have problems with exotic ones like \o/ perhaps because they 
can conceivably be in a real post or in /ASCII art/.

In short, there is a big chance that what you will see is not what I 
wrote. Perhaps it is what I intended.

Post a reply to this message

On 22-7-2009 11:13, David H. Burns wrote:
> Eero Ahonen wrote:
>> David H. Burns wrote:
>>> (Laugh) I love it! What can be off-topic to off-topic?  What you mean, I
>>> think, is that
>>> this topic is forbidden! Or maybe simply unwanted.
>>>
>>
>> On-topic. Your conversation is clearly about Pov-RAY, so it would
>> naturally fit onto the on-topic groups better than to shit-chatting
>> off-topic group :-).
>>
>> -Aero
> I was told I was off topic in the programming group -- or maybe it's 
> just what
> I say, or how I say it, not the subject that's off-topic. But my critics 
> are right;
> I don't know enough detail to really discuss OOP. 

That did not stop other people here to start a lot of threads. ;) So, 
welcome. Take a seat, relax and try to find a role in this bunch of 
looneys. AFAIK we don't have an on-topic poster here yet, so if that is 
what you like...

> I just voice my objections which apparently aren't shared.

They are to a certain extendthey are. The main problem though, apart 
from this being the wrong group is that you restarted a useless 
discussion for the 42nd time.

>:)

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > Yes, I personally do advocate going for strong OOP-support with POV-Ray 4 SDL. I
> > do so as a POV-Ray user, and I do so as a contributing developer.
> >
> > Yes, I did present a serious proposal for a new, OOP-enabled SDL in the povray 4
> > newsgroup some months ago.
> >
> > Yes, being active in the development of POV-Ray 3.7 I *may* happen to personally
> > get my hands dirty on the code of POV-Ray 4's SDL engine.
>
> So it is so after all
> :(

So it is *what* after all? Me single-handedly going to take over the world or
what??

Mwahahaha - Yeeees - I've always wanted to do that...

Ah, BTW & FYI: Me being a contributing developer to POV-Ray doesn't mean that
I'm member of the official dev team. I do contribute code now and then, but as
for making decisions about which direction to go, the buck does *not* stop
here.

Post a reply to this message

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

I have the uncanny feeling that in some years from now I might even agree with
you... >_<

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> The question is... are any POV-Ray "programs" large enough to benefit
> from the extra structuring? I believe the answer is yes, but it's
> somewhat debatable.

I'm quite sure they are - provided we count in a nice set of standard data
containers (variable-size arrays, stacks, queues, lookup lists aka associative
arrays, and maybe some more geometry-oriented like BSP trees, octrees or the
like), and don't want to code them all "hard" into the language or want to stay
flexible for users adding their own (graphs as you might need for physics
simulations, just to give one example of where one could go).

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> [Now the old MS-DOS *.com files really *are* just bare machine code,
> always loaded at a specific machine address...]

Not quite true: They could be loaded at any segment address... OS calls would be
done via invoking INT 21h with particular register values though, if that's what
you mean.

Post a reply to this message

On Wed, 22 Jul 2009 04:05:45 -0500, David H. Burns wrote:

> but it
> apparently allows,
> maybe encourages, writing code so complex as to be almost
> undecipherable.

Google "IOCCC" for some wonderful examples of this. ;-)

Jim

Post a reply to this message

On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:

> What can be off-topic to off-topic?

Why, anything that's on-topic, of course. ;-)

Jim

Post a reply to this message

On Wed, 22 Jul 2009 07:00:37 +0300, Eero Ahonen wrote:

> shit-chatting

Wonderful faux pas. ;-)

Jim

Post a reply to this message

andrel wrote:
> On 22-7-2009 1:26, David H. Burns wrote:
>> andrel wrote:
>>
>>> That you see your smiley does not mean everybody else will.
>>
>> Thanks. Did you see it? I did when I read my own post. I don't think 
>> it shows up in the text in
>> my "sent" file. These matters get complicated.
>> :) (smiley ?)
>>
> 
> I do. In your post, not when replying :) , neither yours nor mine.
> The point I tried to make earlier is that it depends on the mail reader 
> of the person *reading*. You don't have an influence on it. You type a 
> colon followed by a bracket, that is what you sent and what is supported 
> by NNTP. After that somebody is trying to cleverly replace them by 
> rotated smileys, which is OK as long as they get it right :/
> IIRC they have problems with exotic ones like \o/ perhaps because they 
> can conceivably be in a real post or in /ASCII art/.
> 
> In short, there is a big chance that what you will see is not what I 
> wrote. Perhaps it is what I intended.

Thanks, again, Andrel. The smileys work, :/ and \o/ came through as the 
Ascii characters.
I'm using Thunderbird.

David

Post a reply to this message

Jim Henderson wrote:
> On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:
> 
>> What can be off-topic to off-topic?
> 
> Why, anything that's on-topic, of course. ;-)
> 
> Jim

Obviously, but I hadn't thought of it that way.

David

Post a reply to this message

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

There is still some debate about that, of course :)

For one, OOP more closely models how many people think of problems, 
while functional programming more closely models how mathematicians 
think of problems.  It is not yet clear which one is better for managing 
large, complex programs in general (especially since there are many 
things a computer does that are still more closely aligned with 
imperative programming.  These things are easier to wrap in OOP, which 
has concepts for both data and actions).

-- 
Chambers

Post a reply to this message

clipka wrote:
> the buck does *not* stop here.

Shouldn't that be "the Buck"? ;)

-- 
Chambers

Post a reply to this message

andrel wrote:

Unfortunately, it seems to be in the nature of things that useless 
discussion drag
on and recur while the useful ones appear only once for a moment. But 
this one hasn't
been entirely useless to me. :)

The main problem though, apart
> from this being the wrong group is that you restarted a useless 
> discussion for the 42nd time.
> 
>> :)

Post a reply to this message

scott wrote:
> A lot of people just find it makes more sense to 
> have one file that neatly shows the interfaces and another to actually 
> contain the implementation code.

In fact, one of my biggest complaints with C# is the lack of class 
prototypes.  I miss having a public interface which fits entirely on one 
(maybe two) screen(s).  Somehow, it seems to make things easier for me.

-- 
Chambers

Post a reply to this message

On Wed, 22 Jul 2009 20:00:21 -0500, David H. Burns wrote:

> Jim Henderson wrote:
>> On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:
>> 
>>> What can be off-topic to off-topic?
>> 
>> Why, anything that's on-topic, of course. ;-)
>> 
>> Jim
> 
> Obviously, but I hadn't thought of it that way.

That's perfectly OK - I was just kidding around, had hoped the smiley 
would tip that off. ;-)

Jim

Post a reply to this message

> The way this works on the Amiga is that you can't just *call* an OS 
> function. First you have to look up its base address in a table. 
> Basically, memory address 0x00000004 contains a pointer to a table. Every 
> OS function has a unique ID which is an offset into this table, which 
> enables you to lookup the function's base pointer. And then you can jump 
> to it. All of which takes about two-dozen assembly instructions...

On the Acorn there was an instruction called SWI (software interrupt) for 
calling OS and other module functions.  In the assembler it took a number or 
a string as a parameter (the assembler converted the string to the correct 
number), which defined the specific function you wanted to call.  I assume 
when the CPU got to the SWI instruction it jumped to a few lines of OS code 
which figured out where to actually jump to execute the instruction.

When you loaded "modules" to the OS (they were like services under windows) 
each module could register some functions with the OS.  Then you could call 
them with the SWI instruction.  It was pretty easy to use.

You could easily hack the system though by redirecting the interrupt handler 
to your code, calling the real OS handler, then passing control back to the 
calling program.  Of course in your code you could then check for certain 
functions (like reading the contents of a folder) and modify the results :-)

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> > the buck does *not* stop here.
>
> Shouldn't that be "the Buck"? ;)

??

Post a reply to this message

>> > the buck does *not* stop here.
>>
>> Shouldn't that be "the Buck"? ;)
>
> ??

I know in German you use a capital letter for every noun, but in English 
it's usually just for names.

Post a reply to this message

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

Yes. For some reason, this seems to be mandatory in all Linux 
development. I'm not sure why...

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

One assumes that if you don't need foo(), you wouldn't bother including 
the header file. But sure, if the header declares a few dozen functions; 
you might not call every single one of them.

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

Right. So what you're saying is that there's actually a second linking 
stage each time final executable is run?

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

In summary... you can't call the OS from C. You can only write C wrapper 
functions around the assembly code that calls the OS. (And the wrapper 
then of course looks like a normal C function...)

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

I see. So that's the mechanism on the IA32 platform, is it? (I thought 
only the BIOS uses this method...)

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

Interestingly enough, the Motorola 68000 does in fact have two modes of 
operation: "user mode" and "supervisor mode". I have no idea what the 
distinction is.

Additionally, the factory-standard Amigas had the "EC" version of the 
Motorola 68000 CPUs which lack an MMU. You can, however, replace this 
with a version of the CPU that possesses an MMU. Indeed, several 
companies offered the add-on boards, together with the necessary 
software to extend AmigaOS to support virtual memory. This suggests that 
the MMU-enabled variant of the CPU could support memory protection if 
you wanted.

And finally, it's perfectly possible to make a multiuser OS without 
memory protection. It just won't have any memory protection. (Meaning 
one rogue program can crash the whole system.) Arguably not very useful, 
but completely doable.

Post a reply to this message