Functions in .h file and in .c

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

Howdy !

 

When functions are defined in a .c file and reference is to them is in .h file. Like this:

//USART.h

void printString(const char myString[]);

void transmitByte(uint8_t data);
//USART.c
void printString(const char myString[]) {
  uint8_t i = 0;
  while (myString[i]) {
    transmitByte(myString[i]);
    i++;
  }
}

void transmitByte(uint8_t data) {
                                     /* Wait for empty transmit buffer */
  loop_until_bit_is_set(UCSR0A, UDRE0);
  UDR0 = data;                                            /* send data */
}

And when functions defined only in  .h file. Like this:

//USART.h

void printString(const char myString[]) {
  uint8_t i = 0;
  while (myString[i]) {
    transmitByte(myString[i]);
    i++;
  }
}

void transmitByte(uint8_t data) {
                                     /* Wait for empty transmit buffer */
  loop_until_bit_is_set(UCSR0A, UDRE0);
  UDR0 = data;                                            /* send data */
}

What is the difference between these two cases ? The obvious difference is that I need to #include .h file and put .c file into the AS7 project in the first case. And I only need to #include .h file in the second case.

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

There are conventions in C but no specific rules.   i.e. you could use any filename or extension that you like.

 

The convention is:

1.  only put defines, macros and declarations in an H file

2.  put guard statements around the statements so that the body of an H file is only read once.

3.  static inline functions are ok in an H file because they do not require external linkage.

4.  macros are written in UPPER_CASE

 

5.  put executable code in C or CPP files

6.  multiple C, CPP files include the H file to ensure that they all see the same declarations etc.

 

You can flout every convention providing the results are legal C syntax.

 

Most IDEs will look at the file extension to determine how to translate a file.

You will find life easier if you follow conventions accepted by the rest of the world.

But hey-ho,  you can do whatever you want.

 

David.

 

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

If you don't want to follow any of the C conventions why do you want a H file ? (just include the .c file if you put code in it anyway.)

 

 

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

The issue about putting code or data definitions (not just declarations) in a .h file is what will happen if that uart.h happens to be #include'd in more than one C file.  If it is then each will contain a copy of those functions/data and when the linker comes to put everything together it will tell you "XXXX is multiply defined"

 

The rule is therefore pretty simple, don't put anything that would lead to any form of allocation (code or data) into a header file.

 

The one exception to this would be "static inline" C functions. They can be in headers because just including the header makes no code space allocation. It's only at the actual point of invocation that a static inline function allocates code flash. If the header is included in more than one C file and they both invoke the function then,  yes,  both lead to an allocation of space for the code but that's just within the body of the calling functions.  It does not create two separate, callable copies of the code that might confuse the linker (which is why it's so important "static" is used!).

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

http://c-faq.com/decl/decldef.html

 

clawson wrote:
The issue about putting code or data definitions (not just declarations) in a .h file is what will happen if that uart.h happens to be #include'd in more than one C file.  If it is then each will contain a copy of those functions/data and when the linker comes to put everything together it will tell you "XXXX is multiply defined"

The error could be prevented by making them static - but why would you want distinct, identical copies?

 

I have heard that some linkers can try to be "helpful" (sic?) by combining such duplicate definitions?

 

The rule is therefore pretty simple, don't put anything that would lead to any form of allocation (code or data) into a header file.

Absolutely!

 

The one exception to this would be "static inline" C functions.

Indeed.

 

both lead to an allocation of space for the code but that's just within the body of the calling functions.  It does not create two separate, callable copies of the code

Which is, of course, the entire point of inline.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Dec 27, 2016 - 12:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...