> - Splitting a program into more than one source file opens up a whole new 
> world of pain. (Especially if you don't have the benefit of automake.)

You don't have to do this, and for tiny programs it's probably not needed. 
For larger programs I cannot begin to imagine how inefficient it would be to 
have it all in one file, let alone when I want to reuse an existing class in 
another project.

You sound like you need to get a decent book on C++ (NOT C) and get a modern 
IDE (Visuall C++ Express will let you do standard C++ without any .net stuff 
and is free).

Of course if you're stuck writing a whole program in one C file in notepad 
things are gonna suck big time.

Post a reply to this message

scott wrote:
>> - Splitting a program into more than one source file opens up a whole 
>> new world of pain. (Especially if you don't have the benefit of 
>> automake.)
> 
> You don't have to do this, and for tiny programs it's probably not 
> needed. For larger programs I cannot begin to imagine how inefficient it 
> would be to have it all in one file, let alone when I want to reuse an 
> existing class in another project.

The point is, as soon as you have more than one source file, you have to 
manually write header files, manually keep them synchronised with the 
source files, manually figure out the dependency tree, manually compile 
everything one at a time, manually recompile stuff as needed, and 
manually link it all at the end. Get any single step wrong, and at best 
you'll get an incomprehensible linker error; at worst you'll get a 
segfault. Good luck every figuring out why.

If you have automake, a few of those tasks become automated. But 
seriously, I'm used to having a language where you say "compiler my 
stuff" and it hands you a runnable program.

> You sound like you need to get a decent book on C++ (NOT C) and get a 
> modern IDE (Visuall C++ Express will let you do standard C++ without any 
> .net stuff and is free).

I've seen more adverts for C than for C++ (although there certainly seem 
to be quite a few for C++ as well). I think I might still have VS 
installed on my PC at home. I guess it's just finding the motivation to 
use a language which is over-complicated, unsafe and difficult when I 
could instead use one which is clean, simple and easy...

> Of course if you're stuck writing a whole program in one C file in 
> notepad things are gonna suck big time.

Actually, Borland's TurboC for DOS IDE. (Or, alternatively, Vim under 
Linux.)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> The point is, as soon as you have more than one source file, you have to 
> manually write header files, manually keep them synchronised with the 
> source files, manually figure out the dependency tree, manually compile 
> everything one at a time, manually recompile stuff as needed, and 
> manually link it all at the end. Get any single step wrong, and at best 
> you'll get an incomprehensible linker error; at worst you'll get a 
> segfault. Good luck every figuring out why.

  Do you honestly think that an IDE like Visual Studio is not going to
automatically create project dependencies for you?

  In the Unix side of the world knowing a bit of makefile syntax gets you
a long way. It's even possible to create a makefile (at least when using
gnu make) which automates mostly everything, including resolving dependencies.

  And for a small project a simple "g++ *.cc -o myprogram" will do just fine.

-- 
                                                          - Warp

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).
See http://warp.povusers.org/grrr/HateC.html

  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.
In a past thread I tried to teach you a few things about C++ which make
it a lot easier to write small programs quickly, and for a moment I thought
that you had actually learned something. Then some time after that you wrote
a new thread where you showed your attempts at writing something and it
seemed like you forgot or ignored *everything* that I had tried to teach you.
At that point I completely lost hope.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Do you honestly think that an IDE like Visual Studio is not going to
> automatically create project dependencies for you?

It's not entirely clear to me that the source code alone actually 
provides enough information to do this.

Presumably it's simple enough to figure out which source files depend on 
which header files. Not sure how you proceed from there though.

Post a reply to this message

> If you have automake, a few of those tasks become automated. But 
> seriously, I'm used to having a language where you say "compiler my stuff" 
> and it hands you a runnable program.

VS does most of that for you too (you just press F5 and it compiles and 
links the lot, automatically only compiling files that have changed since 
the last build), and you don't need to have separate header files if you 
don't want to.  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.

> I guess it's just finding the motivation to use a language which is 
> over-complicated, unsafe and difficult when I could instead use one which 
> is clean, simple and easy...

From my point of view Haskell looks over-complicated, difficult and slow, 
but I suspect that's just because I haven't bothered to learn much about it.

Anyway, the motivation for you is all those job adverts you say you keep 
seeing...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:

> >   Do you honestly think that an IDE like Visual Studio is not going to
> > automatically create project dependencies for you?

> It's not entirely clear to me that the source code alone actually 
> provides enough information to do this.

  Why wouldn't it? If a source code file needs another source code file,
it will #include it, and the IDE sees that and creates a dependency.

  If you don't #include another source code file then there is no dependency
between those two files.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> From my point of view Haskell looks over-complicated, difficult and slow, 
> but I suspect that's just because I haven't bothered to learn much about it.

  My problem with Haskell is that it's hard to learn. It's like it's 1% of
syntax and 99% of "clever" tricks which you just have to learn from somewhere
(often by word of mouth). And these tricks are often rather exotic and
unintuitive to an imperative/OO programmer.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> If you have automake, a few of those tasks become automated. But 
>> seriously, I'm used to having a language where you say "compiler my 
>> stuff" and it hands you a runnable program.
> 
> VS does most of that for you too (you just press F5 and it compiles and 
> links the lot, automatically only compiling files that have changed 
> since the last build), and you don't need to have separate header files 
> if you don't want to.  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.

Now that's interesting.

1. How does it know which files depend on which other files?

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?

>  From my point of view Haskell looks over-complicated, difficult and 
> slow, but I suspect that's just because I haven't bothered to learn much 
> about it.

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. (C is a lot simpler, it's 
just astonishingly easy to shoot yourself in the foot with it.)

> Anyway, the motivation for you is all those job adverts you say you keep 
> seeing...

Yeah, but let's think about this. I could spend a few months failing to 
learn C++. Hell, maybe I could even write a small program that actually 
works. But I'm up against people who have coded in nothing but C++ since 
they were 9 years old. I don't really stand much of a chance here...

Post a reply to this message

Warp wrote:

>   My problem with Haskell is that it's hard to learn. It's like it's 1% of
> syntax and 99% of "clever" tricks which you just have to learn from somewhere
> (often by word of mouth). And these tricks are often rather exotic and
> unintuitive to an imperative/OO programmer.

I must concurr with Warp here on the "not written down anywhere" part. 
People are doing a lot of very cool stuff with Haskell, but it can be 
maddeningly hard to find answers.

(E.g., somebody implemented a Doom clone in Haskell, and wrote a paper 
explaining how they did it. Except that the paper is utterly 
incomprehensible. It makes no sense at all. It's so badly explained that 
I just can't follow any of it.)

Actually, I think Warp's assessment of Haskell is about right. Haskell 
is like Go. The "rules" are simple, but the "game" is not.

Post a reply to this message

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