Hey Jorg... Quick Question re: .h and .c files

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apologies if this is covered by "standard" (ANSI) C practices, but I could not find it

but what's the rational behind having a .h and .c file for #includes,

Currently I create my defines and prototypes at the top of my .c file and do not use .h files. then I just use #include in my calling program

Is there a reason for splitting the two - seems like it makes for more hassles in file management.

Tom

PS Thanks for all the help you constantly provide this forum[/b]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Conventionally, you never include a .c file. Why should you? In that
case, you could merge both into a single file anyway.

The idea behind all this is that you split up your project into
multiple translation units that get all compiled separately. Then,
you need a way to declare global objects (functions, variables) that
are defined in one C source file and are meant to be exported into
other source files. That's where the header files (.h) come into the
game: you write `extern' declarations for each of these objects into
one or more header file(s), and include this/these header file(s) into
your separate source files. By including them even into the file
where the actual definition of the object is present, you'll ensure
that the header file needs to be consistent with the source file,
otherwise you'd get inconsistent declaration/definition compiler
errors.

So in short:

foo.c:

#include "project.h"

void
foo(int moo)
{
do something with moo;
}

bar.c:

#include "project.h"

int doodle;

int
main(void)
{
doodle = 1;
foo(42);
doodle = 0;
}

project.h:

extern int doodle;
extern void foo(int);

Note the #include "project.h": by convention, the angular bracket
notation (#include ) is used for system-supplied header
files, while double quotes are used for application-supplied header
files.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

[Edit: The real Joerg replied before my message made it in]

I'm not Joerg, but I can still help.

This is a fairly important C question - you do *not* want to include the .c file every time you compile.

The reason is that you link the .c file in seperately - it gets compiled into binary code on its own. So the routines in that .c file say has the routine test_thing(). Now it generates the assembly code for routine test_thing().

If you put the prototypes in the .h file and only include this, what it does is tell the compiler "I've got this routine called test_thing(). The actual source is somewhere else, so don't worry about that". Then the compiler will link to the assembly generated for that routine, which is quite efficent calling it from multiple files.

Now when you include the .c, *every* time you include it more binary will be generated. As well you may get errors about multiple functions having the same name (shouldn't though since they will be local scope). This will blow your code size way way up - the optimizer may figure out what to do, but it is considered very very bad practice.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's a historical observation from an old guy.... back in the day, if you had a big program, it might not compile all in one hunk (not enough memory, even on mainframes), and it was hard to edit big files, and it took literally hours sometimes to compile and assemble and link big programs... not seconds like today... so there was big emphasis on
separate modules and separate compilation and linking them all together with libraries of separately compiled math routines etc. The concept of modules was extended in languages like object pascal, ada, modula, c++, but the need for all this seeming complication might not be obvious to a new guy... just compile up a big file that fills a 32k rom with object code and burn it. Whats the big deal?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've placed all of my "extern uint8_t variable;" declarations in my .c files. Are there any drawbacks to this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heh heh

the need for all this seeming complication might not be obvious to a new guy... just compile up a big file that fills a 32k rom with object code and burn it. Whats the big deal?[/quote wrote:

Not sooo new guy - been at this since the 80's - (and before but then I was a real kid) - My question was just from a syntactical perspective and somewhat compiler/overhead/performance perspective - I will do some fooling around to see what effects there are on code size - proper programming etiquette notwithstanding :wink:

This is a cool plce to hang out - thanks guys!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In short, including C files: :evil: , linking them: :D.

And yes, this is THE place to hang out on the 'net :wink: .

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!