On 2026-09-08 09:25, David Brown wrote:There's no doubt that the C and C++ (prior to modules in C++20) headers are quite a primitive, low-level mechanism. They are very flexible, and can be used for much more than a clear, rigid module system - but with that flexibility to do weird and wonderful things comes the flexibility to do strange, confusing, inefficient or simple incorrect things. The same principle applies to the text-based macros of the C pre-processor. It requires discipline and convention to use well.On 08/09/2026 00:50, Janis Papanagnou wrote:Yeah, that was also my suspicion. (Though I'm not any more practically>It is almost universal practice to have such include guards in header files.
It's even worse; given - as mentioned in another part of the thread -
that #includes are costly we often find some means to avoid not only
duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif)
in the header files but also to prevent accessing the header file in
the first place (by #ifndef LABEL, #include <label.h>, #endif). That
makes such C/C++ code rather messy, IMO. (And makes one appreciate
languages with an inherent good modularization method yet more.)
>
involved in professional C/C++ development so I'm not really up to date
what additional options we nowadays have.)
("#pragma once" is also often used, but while most compilers support it, it is not standard and it can be problematic in some circumstances.) The norm is to have the include guard cover everything except perhaps some comments at the head of the file, and compilers have fast paths to handle such discarded includes very efficiently.Well, I wouldn't actually call it a "problem". - I mean, it's "C" we're
>
So I would not count include guards as a problem in C - think of it more as a quirky syntax for how header files are written.
talking about. :-)
Yes, the syntax (and all the overhead) is what I find annoying. (But
I'm used to it, and it's also not worth complaining. It's effective.)
Where other languages might have "interface module XXX;", C has "#ifndef __XXX__".I'm not feeling competent enough concerning "the best" module interface
methods and their discussion, but I've met a handful languages/methods
during my IT life and the C/C++ "model" is rather at the low end. (But
I've also programmed in languages that didn't have any module-concept
at all. - We've to use what we are supposed to work with.)
And that flexibility also leads to disadvantages when trying to change or improve things - any new solution still has to work with code that includes the same file multiple times intentionally (such as for so-called "x-macros"), or has headers whose functionality depends on macro definitions before inclusion, and so on.
Basically, if you are making a new language, you should include some kind of module system that is better than C has - but it is impractical to try to change C now. (Maybe C could later copy modules from C++, once there has been enough practical experience built up around them. But it would first have to copy namespaces.)
Most serious developers use some kind of IDE or advanced editor, and most such tools can generate include guards automatically when you create a new header file.>We defined our company (coding-)standards to cover that. (And had our
Still, there can be problems when someone does not follow the common practice here.
technical mechanisms to alleviate the burden of the textual overhead.)
I follow that principle too. But not everyone does. So I would have :>Hmm.. - I'm not sure I can follow you here. - If some of our headers
It is also inconvenient when a programmer fails to include sub- includes that are needed, so that the person using the header has to figure out a correct order and manually add any required include files.
had its own dependencies it was the responsibility of that header to
satisfy them. - I recall there were occasionally issues with lacking
consistency, but that was in our project contexts considered a bug.
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
#include <stdint.h>
extern uint64_t make_a_big_number(void);
#endif // #ifndef __NUMBER_GENERATOR_H__
But some people would omit the "#include <stdint.h>" line, and leave that as the responsibility of the person writing the C file. The same applies to dependencies on local header files.
Agreed.>Yes. It's primitive. It does its job. And you should accompany their
C's include system is not hard to use well, but it is certainly possible to use it badly and cause inconvenience to others.
use by standards and conventions.
(Of course that applies to a lot of aspects of C. It's a language that requires more programmer responsibility than some other languages where the tools can do more checks at compile-time, or you have more checks at run-time.)
Les messages affichés proviennent d'usenet.