Products > Programming

nesting of .h files and .h files which start with an underscore

<< < (5/6) > >>

golden_labels:

--- Quote from: peter-h on October 13, 2021, 08:03:47 am ---If you have fred.h and in it you include time.h, and you have two .c files, both need fred.h but only one needs time.h, then it seems dumb to include time.h in fred.h.
--- End quote ---
It’s “fred.h” that requires “time.h”, not some source (.c) files. The source files require it only as a consequence of “fred.h” requiring it. And “fred.h” should be self-contained. If you include “fred.h” in any compilation unit, it must work as it, including providing any dependencies it may require.


--- Quote from: peter-h on October 13, 2021, 08:03:47 am ---IMHO time.h should be included separately in the .c file which needs it.
--- End quote ---
No. Aside from that being impossible to do in practice (you may not even know, what files have to be included), it is code duplication and it is unnecessarily introducing chances for mistakes. By doing so you are both wasting your time and shooting yourself in the foot at the same time. And if this code will ever be used by someone else, you are also confusing them and making them waste time on tracking down weird errors.


--- Quote from: peter-h on October 13, 2021, 08:03:47 am ---Otherwise, every .c file which is getting fred.h will also be getting time.h and you could get a name conflict with some function you have written, etc.
--- End quote ---
No, there can’t be any conflict: those are separate compilation units. And even if that would be a single compilation unit, this is why every header file must have inclusion guards.

ejeffrey:

--- Quote from: peter-h on October 13, 2021, 08:03:47 am ---"Every *file* (including headers) should include exactly the .h files it actually needs."

Maybe I didn't explain it well but I think I can see the answer (there isn't one).

If you have fred.h and in it you include time.h, and you have two .c files, both need fred.h but only one needs time.h, then it seems dumb to include time.h in fred.h. IMHO time.h should be included separately in the .c file which needs it. Otherwise, every .c file which is getting fred.h will also be getting time.h and you could get a name conflict with some function you have written, etc.

Obviously if fred.h itself needs time.h then you have to include tim.h in fred.h. That happens sometimes, but from what I have seen most nested includes are accidental, and since most coders are just trying to get a product to work, if it works, you leave it.

--- End quote ---

Maybe the issue here is your idea of "X needs Y"? In your example kde_ntp.h needs time.h.  maybe explain why you think it doesn't?

madires:
Example on how to manage header files (from, linux' time.h):


--- Code: ---#ifndef _TIME_H
  #define _TIME_H 1

  #include <features.h>
  [...]
#endif

--- End code ---

Siwastaja:
It's beyond me how something such obvious can generate this much confusion.

asdfg.c:

#include <time.h> // needed, because later in this file:
time_t thing;

qwerty.h

#include <time.h> // needed, because later in this file:
void do_thing(time_t arg);


foo.h
// time_t or other time.h things not expressed. #include <time.h> not needed

bar.c
// time_t or other time.h things not expressed. #include <time.h> not needed


It's completely irrelevant to think about what something else includes and if there is nesting or no.

newbrain:

--- Quote from: Siwastaja on October 13, 2021, 03:08:10 pm ---It's beyond me how something such obvious can generate this much confusion.
[...]
It's completely irrelevant to think about what something else includes and if there is nesting or no.

--- End quote ---
Well, I agree with you*, and for me - and, I'm sure, many other contributors here - it's quite clear how this works and what good rules are.

The same cannot be said for people with less experience in C, so much that Google considered the topic worthy of about 4 style guide rules (they are for C++, to be precise, but there are no differences in this case).

I take your last statement as a confirmation that one should never rely on what an header includes: IMO it should be considered a black box, providing only the advertised interfaces and not any side perks grabbed by looking under the hood.
So one should do their homework by explicitly including everything needed (Google and I agree) - but I've also seen somewhat experienced designers failing to realize this, and bad habits are easy to get and spread.

If discussing about this topic here can help someone to write better code, it's worth the (small) effort.

*in fairness, about C, I only remember one minor style thing where I did not.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version