Headers are making my head hurt...

The long version:
I'm experimenting with an old (8-bit, pre-ANSI) C implementation, and I've run out of memory.

A solution given in the manual: "don't despair; split the big source file into two or more smaller source files and compile them separately. They will join up again when you link them." Of course, if I compile each piece separately, the compiler complains about "undeclared identifiers" etc.

Header files seem like a possible solution... but what I've tried doesn't work, and the material I've read seems much more complex than what I'm trying to do.


TLDR: I want to create header files for a long program which has been split into small units. Existing documentation is confusing.

I'd really appreciate any guidance in how to fashion a header file for this situation.

Thanks, Michael

Do you have lots of global variables as well as functions?

It's generally simpler if you restrict the first pass through the code to only move functions that don't depend on global variables.

Let's say your "large" main.c file consists of two functions.

Code:

---

#include <stdio.h>
#include <string.h>

void foo ( const char *s ) {
}

int main ( ) {
    foo("hello");
}

---

In three separate editor windows, open (or create) three files:
- main.c
- functions.c
- functions.h

Initialise functions.c to look like this

Code:

---

#include <stdio.h>
#include <string.h>
#include "functions.h"

---

Initialise functions.h to look like this

Code:

---

#ifndef FUNCTIONS_H_INCLUDED
#define FUNCTIONS_H_INCLUDED

// Prototypes go here

#endif

---

After the system includes in main.c, add the line

Code:

---

#include "functions.h"

---

One by one, you then do the following things.
1. Cut the code for the 'foo' function from main.c
2. Paste the code for the 'foo' function to the end of functions.c
3. Declare a prototype for the 'foo' function in functions.h

So like this.
Main.c

Code:

---

#include <stdio.h>
#include <string.h>
#include "functions.h"

// foo cut from here

int main ( ) {
    foo("hello");
}

---

Functions.c

Code:

---

#include <stdio.h>
#include <string.h>
#include "functions.h"

// foo pasted here

void foo ( const char *s ) {
}

---

Functions.h

Code:

---

#ifndef FUNCTIONS_H_INCLUDED
#define FUNCTIONS_H_INCLUDED

// Prototypes go here
void foo ( const char *s );

#endif

---

After each move of a function, compile everything to make sure it still works.

Thank you for your reply. Ok I've read through your answer several times, and looked at some other tutorials. I tried again, and either I'm still doing it wrong or the compiler isn't very good...

I'm testing with two files:
INIT.C has lots of global variables, and one function called wipe() which clears the screen.
INTRO.C uses some of the global variables, as well as the wipe() function.

Here's what I did:


INIT.C

Code:

---

#include <stdio.h>
#include <string.h>

#define true 1
#define false 0

int lots      =1;
int of        =2;
int variables =3;

wipe() { code };

---

INIT.H

Code:

---

#ifndef INIT_H_INCLUDED
#define INIT_H_INCLUDED

#define true 1
#define false 0

extern int lots, of, variables;

wipe();

#endif

---

INTRO.C

Code:

---

#include <stdio.h>
#include <string.h>
#include "INTRO.H"

main()
{
foo() { code with variables };
wipe();
}

---

INIT.C compiles fine, but INTRO.C goes all the way to the end and freezes. I realize this could be a bug in the compiler, but am I doing anything wrong in the examples above?

You show a file called INIT.H, but you include a file called "INTRO.H"

INIT.C should include INIT.H
This keeps the prototype/definition of wipe() in sync, and you don't have to keep redefining true and false.

Copy/pasting your actual console/terminal log of the compilation would be useful.

Sorry that was a typo, I should have chosen different names for my example! INTRO.C does indeed say #include "INIT.H"

I wish there was a terminal log/error message to copy and paste... It's an old Commodore 64 implementation, and at best I'm lucky to get "syntax error" or "illegal assignment", at worst it just freezes up like it's doing now.

I think I need to download a version of C for Windows and get it working first, before trying to figure out what's going on with the Commodore version. Thanks for your suggestions, I'll come back and update when I've played with it in Windows!

Yeah, old 1980's 8-bit micro C implementations were a challenge for sure.

I think I figured it out. I got everything working in a browser compiler (OnlineDGB) and copied the working headers over to the Commodore for partial success.

I haven't figured out when to use "extern". In OnlineDGB and on the Comodore 128 the program works fine with or without extern. But without extern, the Commodore 64 throws a lot of errors--and with extern it still runs out of memory! Oh well, it was worth a try. (There are always other solutions like cross-compilers for Windows)

Thanks for your help, it really helped me to get a grasp on headers.

Quote:

---

Originally Posted by gmontag451

I think I figured it out. I got everything working in a browser compiler (OnlineDGB) and copied the working headers over to the Commodore for partial success.

I haven't figured out when to use "extern". In OnlineDGB and on the Comodore 128 the program works fine with or without extern. But without extern, the Commodore 64 throws a lot of errors--and with extern it still runs out of memory! Oh well, it was worth a try. (There are always other solutions like cross-compilers for Windows)

Thanks for your help, it really helped me to get a grasp on headers.

---

All functions are by default, "extern", unless declared/defined as static. At least in a Standards Compliant compiler. Not a error to define them as extern, but not needed.

I would guess that any compilers for Commodore 64 or 128 are not Standards Compliant.

I would strongly urge you to abandon both Commodore "computers", and move to Windows, using Cygwin, or MinGW-64, or even better, Linux.

Or use the CC65 cross-compiler.

Quote:

---

Originally Posted by christop

Or use the CC65 cross-compiler.

---

Not recommended!

From the CC65 website:
"Please note that the compiler does not support the C99 standard and never will. c99 mode is actually c89 mode with a few selected C99 extensions."

Time to move up to Gcc or Clang on Windows or Linux.

Quote:

---

Originally Posted by rstanley

Not recommended!

From the CC65 website:
"Please note that the compiler does not support the C99 standard and never will. c99 mode is actually c89 mode with a few selected C99 extensions."

Time to move up to Gcc or Clang on Windows or Linux.

---

I agree that for general programming, GCC or Clang on a modern computer is preferred, but for those wanting to develop for the old personal computers like the Commodore, CC65 is one of the best C compilers available. Surely it can't be worse than the native compiler that OP is currently using?

Quote:

---

Originally Posted by rstanley

I would guess that any compilers for Commodore 64 or 128 are not Standards Compliant.

---

Due to age and memory constraints, they most certainly are not.

Quote:

---

Originally Posted by rstanley

I would strongly urge you to abandon both Commodore "computers", and move to Windows, using Cygwin, or MinGW-64, or even better, Linux.

---

Thanks, I'll look into Cygwin an Clang. I'm not an experienced programmer, but I'm familiar with MinGW and Gcc, in both Windows and Linux.
The point of this project was to get a specific program working on the C64, which is the computer (no quotes needed! :biggrin: ) which I grew up with.

Quote:

---

Originally Posted by christop

Or use the CC65 cross-compiler.

---

I think you're right, I've used CC65, and cross-compiling is probably the better/only solution, even if it's not as fun!

Quote:

---

Originally Posted by gmontag451

I think you're right, I've used CC65, and cross-compiling is probably the better/only solution, even if it's not as fun!

---

I'm just curious, but which C64 C compiler are you using? The only one I've heard of is Super-C. I've never played with it myself, but I can see how it would be fun to get a program working with it (it would have lots of nostalgia value since I also grew up with the C64 and used mine quite a bit until about 10 years ago).

I just added cc65 to development MINGW-packages-dev/mingw-w64-cc65 at master * msys2/MINGW-packages-dev * GitHub git repo.

In case, you are using MSys2.

Edit: I have not really used cc65; I am trying to port some m6502 open source projects to the m6809 CPU used by the Radio Shack Color Computer.
Step 1. Is porting the m6502 projects to MSys2.

Tim S.

Quote:

---

Originally Posted by christop

I'm just curious, but which C64 C compiler are you using? The only one I've heard of is Super-C. I've never played with it myself, but I can see how it would be fun to get a program working with it (it would have lots of nostalgia value since I also grew up with the C64 and used mine quite a bit until about 10 years ago).

---

I'm using the same software I originally learned C on; Better Working Power C (which was originally called C Power). Power C has a really nice interface and workflow but there are some frustrating bugs, the documentation is wanting, and there are baffling inconsistencies between the C128 and C64 version. I've never used any other on the 64, but there's really no excuse not to and I'll probably try out Super-C over Christmas break.