Posted By: DLively
.h vs .c - 04/13/15 18:29
Noob Question.
Why would I want to use a header file, instead of a c file?
Why would I want to use a header file, instead of a c file?
.h vs .c
Posted By: 3run
Re: .h vs .c - 04/13/15 18:36
As far as I know, they are used for different purposes (.c and .h).
Here, I've found this over the internet (about libraries and headers):
As far as I know, header file could help you to avoid 'undeclared function' issues, if you use function which is placed under the one that calls it, f.e.:
You can declare that 'makeBeep()' in the header file, so the whole .c file will 'know' the list of available functions (variables etc).
I might be wrong, but this is how I see it so far.
Best regards
Here, I've found this over the internet (about libraries and headers):
Originally Posted By: What's the difference between a header file and a library?
Think of both like this (Disclaimer: this is a really high-level analogy 
..
The header is a phone number you can call, while...
...the library is the actual person you can reach there!
It's the fundamental difference between "interface" and "implementation"; the interface (header) tells you how to call some functionality (without knowing how it works), while the implementation (library) is the actual functionality.
..The header is a phone number you can call, while...
...the library is the actual person you can reach there!
It's the fundamental difference between "interface" and "implementation"; the interface (header) tells you how to call some functionality (without knowing how it works), while the implementation (library) is the actual functionality.
As far as I know, header file could help you to avoid 'undeclared function' issues, if you use function which is placed under the one that calls it, f.e.:
Code:
void callFunction(){
makeBeep();
}
void makeBeep(){
beep();
}
I might be wrong, but this is how I see it so far.
Best regards
Posted By: FBL
Re: .h vs .c - 04/14/15 17:59
Header Files should be "headers", meaning they should not contain functionality. An exception may be made for #define macros.
Usually you place there extern declarations (not used in Lite-c) for making interfaces to other c-Files known, prototypes, enums, value defines and similar.
It also depends on what you want to do with your header file. Some people even have "external" headers which may be included by foreign c Files and "internal" headers which are included by the belonging c file only.
Content you would normally put into functions however should not be found in a header, variables normally neither (despite their extern declaration) - but since Lite-C does not support externals many users declare their variables in the header as compromise.
Usually you place there extern declarations (not used in Lite-c) for making interfaces to other c-Files known, prototypes, enums, value defines and similar.
It also depends on what you want to do with your header file. Some people even have "external" headers which may be included by foreign c Files and "internal" headers which are included by the belonging c file only.
Content you would normally put into functions however should not be found in a header, variables normally neither (despite their extern declaration) - but since Lite-C does not support externals many users declare their variables in the header as compromise.
Posted By: FBL
Re: .h vs .c - 04/14/15 18:06
The most confusing point is, that Lite-C unlike the usual C compile/link process does not build an object file per c file and link them together. This means you also include c file like you normally only would do with a h file, which sort of kills the normally quite clear difference.
Posted By: DLively
Re: .h vs .c - 04/17/15 15:31
Okay,
I've had to read this thread once or twice and find a couple examples along with these to clear things up a bit further but its starting to make sense now.
Thanks for clearing this up, guys
I've had to read this thread once or twice and find a couple examples along with these to clear things up a bit further but its starting to make sense now.
Thanks for clearing this up, guys