How to use H-files

[Ruud]

Hallo allemaal,


This is my first message to this group. Until now I mainly wrote
programs in Turbo Pascal. But now I'm involved in a project were
knowledge of C is needed. I'm not unfamiliar with C, but the last time
I used it was maybe 8 years ago.

I wrote quite some programs in TP and one goal is to translate them
into C. In time I created some common, so called, units. I already
found out that I can include a C source using '#include "unit.c"'. But
all programs I know of use '#include <xxxx.h>'. I found some programs
using routines declared in other programs and both seemed to be linked
by an H file. But whatever I tried, I received error messages. (I'm
using Turbo C 3.1 for the moment)

Of course I tried to search the Internet for answers but I either
found nothing or was flooded with links that didn't provide the answer
I needed (mostly caused by not being native English spoken). Can
anybody give me some links to show me how to use #include or tell me
here?

Many thanks in advance!


--
___
/ __|__
/ / |_/ Groetjes, Ruud Baltissen
\ \__|_\
\___| http://Ruud.C64.org

 

[user923005]

Hallo allemaal,

This is my first message to this group. Until now I mainly wrote
programs in Turbo Pascal. But now I'm involved in a project were
knowledge of C is needed. I'm not unfamiliar with C, but the last time
I used it was maybe 8 years ago.

I wrote quite some programs in TP and one goal is to translate them
into C. In time I created some common, so called, units. I already
found out that I can include a C source using '#include "unit.c"'. But
all programs I know of use '#include <xxxx.h>'. I found some programs
using routines declared in other programs and both seemed to be linked
by an H file. But whatever I tried, I received error messages. (I'm
using Turbo C 3.1 for the moment)

Of course I tried to search the Internet for answers but I either
found nothing or was flooded with links that didn't provide the answer
I needed (mostly caused by not being native English spoken). Can
anybody give me some links to show me how to use #include or tell me
here?

From the C-FAQ:

10.6: I'm splitting up a program into multiple source files for the
first time, and I'm wondering what to put in .c files and what
to put in .h files. (What does ".h" mean, anyway?)

A: As a general rule, you should put these things in header (.h)
files:

macro definitions (preprocessor #defines)
structure, union, and enumeration declarations
typedef declarations
external function declarations (see also question 1.11)
global variable declarations

It's especially important to put a declaration or definition in
a header file when it will be shared between several other
files. (In particular, never put external function prototypes
in .c files. See also question 1.7.)

On the other hand, when a definition or declaration should
remain private to one .c file, it's fine to leave it there.

See also questions 1.7 and 10.7.

References: K&R2 Sec. 4.5 pp. 81-2; H&S Sec. 9.2.3 p. 267; CT&P
Sec. 4.6 pp. 66-7.

 

[user923005]

No.  Do not do that.  For emphasis: DO NOT DO THAT.  Including a
file with a ".c" extension is a sure sign of poorly designed
code that will cause instant nausea in a potential maintainer.

I do it sometimes for optimization (it allows the compiler to inline
better for some compilers).
It does have another beneficial side effect -- it usually forces you
to create idempotent header files.

Then I create two projects -- the normal build project has separate C
files and the optimization project has one file like this:

#include "project.h"
#include "file01.c"
#include "file02.c"
#include "file03.c"
#include "file04.c"
#include "file05.c"
#include "file06.c"
#include "file07.c"
#include "file08.c"
#include "file09.c"
#include "file10.c"

Of course, the actual files will have better names than that.
On the other hand, I do agree with you. That sort of evil trickery is
not a good idea unless you need the last little greasy bit of speed.
And some compilers are smart enough to accomplish the same thing
without the cheesy inline trick.
[snip]

 

[Richard Bos]

This is my first message to this group. Until now I mainly wrote
programs in Turbo Pascal.

Ah, dat verklaart weer iets meer van de economische situatie

I wrote quite some programs in TP and one goal is to translate them
into C. In time I created some common, so called, units. I already
found out that I can include a C source using '#include "unit.c"'.\

Not a good idea.

But all programs I know of use '#include <xxxx.h>'. I found some programs
using routines declared in other programs and both seemed to be linked
by an H file. But whatever I tried, I received error messages. (I'm
using Turbo C 3.1 for the moment)

Of course I tried to search the Internet for answers but I either
found nothing or was flooded with links that didn't provide the answer
I needed (mostly caused by not being native English spoken). Can
anybody give me some links to show me how to use #include or tell me
here?

You put your code in a .c-file. You put all the declarations from that
file which you want to export to other parts of the program in a
h-file. Note: declarations, _not_ definitions. Then you #include
"module.h" when you want to use functions from module.c in another
module.
All that does, and all it needs to do, is declare to the using function
how it should call the module function, or what the module- defined
object looks like; what that function does, or what that object
contains, is not something that need, or indeed should, be defined
everywhere.
Then, you compile all modules, and link them together. This is something
your Turbo Pascal system did as well, but it did it for you, in the
background. How you perform this step depends on which compiler system
you use; make files are a common solution, but so are IDE-dependent
project files.

(Note: use #include <standard-header.h> for Standard and other system
headers, and #include "my-own-header.h" for private headers.)

Richard

 

[Ruud]

Hallo William,

compile main.c and a.c separately.
link main.o and a.o to produce executable.

What did you try that didn't work?

I'm using Borland C++ V3.1 and all I do is press Ctrl+F9 to start the
program. That is, if there are no errors present. Thus BC those all
the work for me.



Hallo allemaal,


This is the contents of the file MP_ASM00.C, no header or anything
else:

#include <stdio.h>

int CheckMacro(int by)
{
printf("-- %d --\n", by);
return(by+1);
}


This is the contents of the file MP_ASM.C


#include <stdio.h>
#include "mp_asm00.c"


main()
{
printf("-- 1 --\n\n");

printf("-- %d --\n\n", CheckMacro(4));

printf("-- 9 --\n\n");

return(0);
}


No errors, output as expected.


MP_ASM.H looks like this, just one line:

int CheckMacro(int by);


I added one line to MP_ASM00.C:

#include "mp_asm.h"


And in MP_ASM.C I replaced the line including MP_ASM00.C with the same
one mentioned above. Compiling it doesn't produce an error, running it
does:

•Linker Error: Undefined symbol _CheckMacro in module MP_ASM.C


Adding the line "extern int CheckMacro(int by);" above "main()"
doesn't change anything. So what am I doing wrong!

Many thanks in advance!


--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org

 

[Spiro Trikaliotis]

Hello Ruud,

nice to read you here.

I wrote quite some programs in TP and one goal is to translate them
into C. In time I created some common, so called, units. I already
found out that I can include a C source using '#include "unit.c"'. But
all programs I know of use '#include <xxxx.h>'. I found some programs
using routines declared in other programs and both seemed to be linked
by an H file. But whatever I tried, I received error messages. (I'm
using Turbo C 3.1 for the moment)

To speak in the words of TP units, the .h file ("unit.h") is similar to
the interface part of the TP unit, while the .c file ("unit.c") is
similar to the implementation part of the TP unit.

So, instead of writing everything into one file, you normally split it up
into two (or, sometimes, even more) files.

Note that the C approach is much more flexible than the TP approach. It
is so flexible that it even allows you to shoot yourself in the foot.

Hope this helps for a start.

Regards,
Spiro.

 

[Ben Bacarisse]

This is the contents of the file MP_ASM00.C, no header or anything
else:

#include <stdio.h>

int CheckMacro(int by)
{
printf("-- %d --\n", by);
return(by+1);
}


This is the contents of the file MP_ASM.C

#include <stdio.h>
#include "mp_asm00.c"

main()
{
printf("-- 1 --\n\n");
printf("-- %d --\n\n", CheckMacro(4));
printf("-- 9 --\n\n");
return(0);
}

No errors, output as expected.

OK, but just to be clear, you now know that putting a function
definition in a file that is #included is not a good idea. Presumably
what follows is the problems you encounter as you try to fix this.

MP_ASM.H looks like this, just one line:

int CheckMacro(int by);


I added one line to MP_ASM00.C:

#include "mp_asm.h"


And in MP_ASM.C I replaced the line including MP_ASM00.C with the same
one mentioned above. Compiling it doesn't produce an error, running it
does:

•Linker Error: Undefined symbol _CheckMacro in module MP_ASM.C

So far so good. By the way, this is not run-time problem. The term
"compiling" is often used to mean both compiling (translating your C
into object code) and linking (combining one or more object modules
and libraries into a finished runnable program).

Adding the line "extern int CheckMacro(int by);" above "main()"
doesn't change anything.

No, it won't. extern is the (correct) default for function
declarations and adding another one dill not help.

So what am I doing wrong!

The trouble is that you have not told your compiler/linker/IDE that
this program is made from two object modules: MP_ASM.OBJ and
MP_ASM00.OBJ. If you do that the system will know to link these two
together to make you program. How you do this depends on you system
and I know nothing about that, sorry. There will be some what to say
that this "project" has two compilation units that need to be compiler
and linked together.

 

[viza]

Hi

... all programs I know of use '#include <xxxx.h>'. I found some
programs using routines declared in other programs and both seemed to
be linked by an H file.

In addition to what others have said, remember that foo.h isn't always
the same as foo.H.

On some systems .h is used for c header files and .H is for C++ headers.

Trying to use one when you mean the other may result in file not found,
or perhaps two different files with these two different names might exist
in the same directory.

 

[Ruud]

Hallo allemaal,

 There will be some what to say that this "project" has two....

Bingo, that was the magic word! Like Dephi, BC works with projects. I
completely forgot about that. I created a project, added the two C
programs and things worked!
Thanks!


@Lorenzo:

Turbo Pascal is still used in 2008?

I write emulators that write best under DOS. Therefore I need
something that can create programs that can run in DOS. Hence Turbo
Pascal, and now BC31.


@all others:
Thank you for your input and kind help!

--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org

 

[Nate Eldredge]

@Lorenzo:

I write emulators that write best under DOS. Therefore I need
something that can create programs that can run in DOS. Hence Turbo
Pascal, and now BC31.

[plug]

If your DOS systems are running on at least a 386, you might find it
worth your while to look into DJGPP, which is a port of GCC to DOS,
together with a standard library. This will give you access to a free
modern 32-bit C compiler and tools that should be better maintained than
Borland C, and avoids a lot of the 16-bit annoyances (near and far
pointers, 640K limit, etc).

http://www.delorie.com/pub/djgpp/
news:comp.os.msdos.djgpp

 

[Ruud]

Hallo Nate,

If your DOS systems are running on at least a 386,

FYI, it is a P4 3 GHz.
The reason I run BC 3.1 is the fact that it has a IDE I'm used to.
Yesterday I ran BC 4.5, which is Windows orientated and.... I switched
back to 3.1

http://www.delorie.com/pub/djgpp/

Only seeing a directory I found out I had to go to http://www.delorie.com/djgpp.
There I was confronted with a survey. After too many questions that
became too personal I ended the session, restarted the site and got a
menu. But whatever I clicked, I ran into this survey again. I'm
terribly sorry but this was one of the annoying sites I ran into.

But please don't take this personal; I appreciate it very much that
you pointed me to another compiler because I realize I cannot stick to
BC31 forever. One of my goals at the end is to support VICE
(www.viceteam.org) and most likely I'll use the C compiler they are
using as well (CygWin IIRC).

--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org

 

[Nate Eldredge]

Hallo Nate,



FYI, it is a P4 3 GHz.
The reason I run BC 3.1 is the fact that it has a IDE I'm used to.
Yesterday I ran BC 4.5, which is Windows orientated and.... I switched
back to 3.1

DJGPP has an IDE called RHIDE which is designed to be very similar to
the Borland IDE. So you might be interested in that.

Only seeing a directory I found out I had to go to http://www.delorie.com/djgpp.
There I was confronted with a survey. After too many questions that
became too personal I ended the session, restarted the site and got a
menu. But whatever I clicked, I ran into this survey again. I'm
terribly sorry but this was one of the annoying sites I ran into.

You're not offending me; I didn't put the survey there It does sound
annoying. I've done some work with DJGPP in the past and thought it
might be useful, that's all.

I don't see a survey when I go to that site. There is a link for a
survey at the bottom, that's all. Maybe my browser is blocking a
pop-up; you might be able to get yours to do the same.

You can also get the files via ftp at

ftp://ftp.delorie.com/pub/djgpp/current

which would be free of such annoyances. Begin by reading
ftp://ftp.delorie.com/pub/djgpp/current/v2/readme.1st .