Questions regarding splitting project into multiple files !!!!

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

I have some confusion that I want to clear out.

Recently my project got somewhat big and I can't manage it in a single C file, so I split it into multiple files, which raises some concerns :-

 

Q.1 In multi file project each C file will be compiled independently and then linked together, does it generate different code than as oppose to creating whole project in one single C file and compiling that? I.e Does it produce less optimized code ?

Q.2 Including a header file where it is not needed, does it have any detrimental effect on code? Like say I include all my header files in single header file and than I include that in every C file. Is this bad or it doesn't matter ? 

Q.3 Consider I have three files,

 

My_Interface.h
My_Interface.c
main.c

 

I see many times it's recommended to include .h file in it's own .c file but as I understand .h file is made for including in other .c files like main.c etc. What is the purpose of doing that ? The program produces no error even if I don't do that. ( by not including .h file into it's own .c file)

 

Thank you for time.

This topic has a solution.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan

Last Edited: Mon. Apr 5, 2021 - 11:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Heisen wrote:
I see many times it's recommended to include .h file in it's own .c file but as I understand .h file is made for including in other .c files like main.c etc. What is the purpose of doing that ? The program produces no error even if I don't do that. ( by not including .h file into it's own .c file)

 

It is 'legal' for the c file that contains the function definition (ie. the code that implements the function)

eg.

void foo(void)

{

    /* some code */

}

not to have first seen a declaration (in the header)

eg.

void foo(void);

 

In this case, the definition also acts as a declaration.

However, it means there is no way for the compiler to be able to check that the declaration in the header (as used by other c files) actually matches the definition of the function.

Hence why it is always recommeneded for a c file to include it's own header as it were.

(There are compiler options to provide a warning if you forget to do this eg. -Wmissing-prototypes)

 

 

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

I can't manage it in a single C file  

What exactly do you mean by that?  It is very easy to search one file to find something (ctrl+F), rather than opening 30 different files to look around for something (where are all the places in this program I used the hamburger function?).  Of course, that is not the only consideration, but hard to beat for efficiency.  Some text editors may be operable with more than one file at a time, making it less painful.  So it can depend a lot on the tools at hand. If you have a file that is 100% finished & verified, then you can keep it separated as a known good entity (such as you already do if using libraries that you didn't write yourself--you assume they are good).   

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Heisen wrote:
In multi file project each C file will be compiled independently and then linked together, does it generate different code than as oppose to creating whole project in one single C file and compiling that?
Potentially yes

Heisen wrote:
I.e Does it produce less optimized code ?
Usually not especially with Link Time Optimization (LTO)

Heisen wrote:
Including a header file where it is not needed, does it have any detrimental effect on code?
No though a linter may generate an information message.

Heisen wrote:
Like say I include all my header files in single header file and than I include that in every C file. Is this bad or it doesn't matter ?
No answer; IIRC, one RTOS, μC/OS, has one header file.

 


LTO Visibility — Clang 12 documentation

https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Optimize-Options.html#index-flto

 

edit :

https://github.com/weston-embedded/uC-OS2/blob/master/Source/ucos_ii.h

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Apr 5, 2021 - 12:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Heisen wrote:
What is the purpose of doing that ?

 

Um... Strange question.

 

1. Your header files will contain declarations of common data types (structs, typedefs etc.) and manifest constants (macros etc.), introduced by your .h/.c combination. In you don't include your .h in to your .c, these entities will not be visible in .c file. Which makes no sense. It is not possible to write the .c file without seeing these declarations. (You said your code compiles, but that simply means that your example is not even remotely representative).

 

2. The header file will usually contain declarations of external functions, while the .c file will contain their definitions. A quality compiler will normally verify that declarations properly match the definitions (return type, parameters etc.). This is a good thing to have, since otherwise it is easy to end up with a bunch of quiet errors.

 

3. Function and object declarations made in the header serve as forward declarations for the .c file, which means that it no longer matters in which order the functions in .c file are defined: they can invoke each other without worrying whether the function is already declared or not.

 

4. There are definitely more.

Dessine-moi un mouton

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

Part of the point of modularity is to limit the

number of things one must think about at a time.

Having one big header defeats that somewhat:

More things are visible than you would want to change.

Moderation in all things. -- ancient proverb

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

 

Okay, read twice.

 

avrcandies wrote:
If you have a file that is 100% finished & verified, then you can keep it separated as a known good entity

 

Yeah, this was mostly the reason. I am not using any libraries.

skeeve wrote:

Part of the point of modularity is to limit the

number of things one must think about at a time.

Having one big header defeats that somewhat:

More things are visible than you would want to change.

 

I got it. Thanks.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan

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

Thanks for the clarification.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan

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

To many, those ARE libraries, or can be.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

just a comment to Q.1

 

 

From the old days it made a difference in compile time, (that is why you have build and build all as options), but with new fast computers it normally don't matter anymore.

 

It don't generate the same code, with one big file it see everything and therefore make better code. (some compilers can treat a hole project as one file, and then it will make the same code)   

(I have not used it but my guess is that it's a preprocessor option)

Last Edited: Tue. Apr 6, 2021 - 08:24 AM