Re: #include recommendation

kid joe wrote:
Hi,

In the next release of the C standard, Id like to see an extension of the
#include directive to allow multiple files to be included on a single line.

Many files start with a large number of #include lines like
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <platform_specific1.h>
#include <platform_specific2.h>

and often many more than this!

This shouldnt be the first thing you see when you open a C file!

Why not allow

#include <stdio.h>,<stdlib.h>,<string.h>,<platform_specific1.h>,<platform_specific2.h>

or

#include <stdio.h><stdlib.h><string.h><platform_specific1.h><platform_specific2.h>

for more flexibility in how the C source file is laid out?

No, I think the old version is a lot more readable and desirable.

The header files are documentation!
When I read a file, I should understand what it is the meaning of the
different identifiers. So I recommend programmers to explicitly
write all header files which provide the used interface (API).

You may wonder how many files forgot to include needed headers
(which normally I see when compiling with other architectures
and/or new libraries). Namespace is not unique, so
with a catch all #include "myproject.h" I don't see if foobar is
a home made of if it is the common foobar() found in the library
libfoo.

So, to your proposal:
Check the quoted text and tell me if you included <stdargs.h>.
With the old methods the eyes tend to parse quicker the headers;
in your proposal the eyes should parse horizontally (and
vertically if there are much more headers) and you see that it
take a lot more time (relative to old methods).

BTW python allow multiple import:
import foo, bar, han, spam
but for the coding style for standard module (and good programs)
mandate one lime per module.

ciao
cate
.

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... but you can hardly blame the consequences on the Standard headers. ... to use strndup, it's personal matter between user and his C ...
    (comp.lang.c)
  • Re: Header Files and Interfaces Yet Again
    ... >> Standard, I will have to adjust my headers to match the implementation. ... I can use the declarations in the headers to compile my ... > I do not that much about compiler design as to asses whether this is ...
    (comp.lang.cpp)
  • Re: .h for standard headers
    ... The fundamental arrogance in the C++ Standard was thinking that ... It declares all names within namespace std. ... the world on notice that headers like will one day go ... a couple of libraries do meet these requirements. ...
    (comp.lang.cpp)