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