All inclusive header files?

A

Anne Onime

I notice that there are a lot of header files eg. <stdio.h>,
stdlib.h> and <conio.h> which a programmer must include
in order to use certain commands. Is there a all-inclusive
file?
 
P

Peter Nilsson

Anne Onime said:
I notice that there are a lot of header files eg. <stdio.h>,
stdlib.h> and <conio.h> which a programmer must include
in order to use certain commands.

Is there a all-inclusive file?

Not a standard one no. You could write your own, but why bother!
 
M

Malcolm McLean

I notice that there are a lot of header files eg. <stdio.h>,
stdlib.h> and <conio.h> which a programmer must include
in order to use certain commands. Is there a all-inclusive
file?
No.
If we were designing C from scratch we'd probably just have one header
for all standard library functions. However we've got the current set
of 20 or so as a legacy. I'm not sure what the original justification
was, but some platforms didn't have math libraries, for instance,
which would justify a separate header for math.h.
 
J

jacob navia

Le 07/03/11 09:34, Vivien MOREAU a écrit :
If we were designing C from scratch we'd probably just have one header
for all standard library functions.

Actually, that is what the C compiler redesigned by Ken Thompson
for Plan 9 from Bell Labs does:

I proposed the same thing in thisn forum not long ago. In my compiler
system the file is called "stdheaders.h"

And if it is not standard C I really do not care. The question is:

Is it useful?

If yes, use it, if not do not use it.
 
M

Malcolm McLean

Is it useful?

If yes, use it, if not do not use it.
The problem is that sometimes something seems useful, only for the
disadvantages to become all too apparent later on.

In this case, the extra dependency could wreak havoc with attempts to
integrate code from two projects.
 
K

Keith Thompson

China Blue Condition said:
It's not hard to create one for yourself. In a unix makefile you can do
something like


om.h: /usr/include
(cd /usr/include; ls *.h | awk '{print "#include <" $0 ">"}') > om.h

executable: om.h zardoz.c
cc -o executable zardoz.c


And then zardoz.c begins with
#include "om.h"
...


Other operating and build systems likely offer something similar.

For those not familiar with Unix commands and Makefile syntax,
that create a file "om.h" with a #include directive for every file
in that directory whose name ends in ".h".

That's not a good idea.

One system I'm currently using has 165 such files; another has 414.
I just tried your idea on the latter system and got 8003 lines of
error messages.

I haven't looked into the messages, but there could well be
dependences among some of the headers. Even in the best case, most
of these are certainly non-standard, and will introduce identifiers
that could conflict with user identifiers. And there's no guarantee
that /usr/include is the only place the compiler looks for standard
headers.

You can get a list of the standard headers from the C standard --
but IMHO it's generally better just to include the headers you need.
 
B

Bartc

Anne Onime said:
I notice that there are a lot of header files eg. <stdio.h>,
stdlib.h> and <conio.h> which a programmer must include
in order to use certain commands. Is there a all-inclusive
file?

That's one of the annoyannces of C, trying to remember exactly which header
some obscure standard function uses, without having to go and look up docs.

It's possible to create your own personal header file of course, which
includes the 20-odd standard headers, but if you try and post a program with
such a header here, noone will be able to compile it!
 
L

Lew Pitcher

That's one of the annoyannces of C, trying to remember exactly which
header some obscure standard function uses, without having to go and look
up docs.

That's the "annoyance" of /any/ high level programming language. If the
feature is "common", you usually have it's properties (including which
header to use) memorized; if the feature is "obscure" then you would have
to look it up in the documentation anyways.

This is true of C or Java or COBOL or Assembler.
It's possible to create your own personal header file of course, which
includes the 20-odd standard headers, but if you try and post a program
with such a header here, noone will be able to compile it!

And, of course, it won't have the critical header for that one obscure
feature, which will require you to go back to the books and read. And when
that one obscure feature has multiple header dependencies, you will then
puzzle over whether your "own personal header" will satisfy the
dependencies or not. Good luck with that.

Having spent over 30 years as a professional developer, I've found
that "reading the documentation" is just part of the profession. I wouldn't
trust the code written by anyone who refuses to read the documentation;
it's highly likely that they've missed some critical piece of information,
and introduced bugs into the application, bugs that /I'd/ have to fix.

Just my 2 cents worth
 
G

Georg Bauhaus

Keith Thompson said:
but IMHO it's generally better just to include the headers you need.

My job was to handle sources with "wildcard
inclusions" in them. To understand the files and learn the
structure of the program. All inclusive header files can be
as helpful as a large collection of global variables.

instead of including everything everywhere,
you still could save some typing and shorten the list
of includes by placing much needed functions in
a separate file. Have this file include the many headers
needed for the ubiquitous functions. A corresponding
header ("logging.h", "debug.h", etc) will make
them available as needed. Call it a module.

A module makes changing the software a lot easier.
For example, if you wanted log entries to be written
neither by stdio nor by conio, you just change your
extra file of ubiquitous logging functions, and nothing
else.
 
E

Eric Sosman

That's one of the annoyannces of C, trying to remember exactly which header
some obscure standard function uses, without having to go and look up docs.

Can we call the everything-is-everywhere strategy "immodularity?"
 
M

Mark Bluemel

It's not just the headers, the whole c language is like that.
Anytime that I have to use a feature of the language
and I can't remember exactly how it works,
I have to look it up.

It's one of the major problems of c.

You want my new language DWIW (Do What I Want) which is due for
release Real Soon Now (just after I get my flying car and fusion
power becomes commercially viable).

Once mind-computer interfaces are improved, I intend to release
version 2, renamed to DWIM (Do What I Meant). V3 - DWIN (Do What
I Need) - is awaiting Strong Artificial Intelligence and may be
delayed until after the Singularity.
 
S

Stefan Ram

Mark Bluemel said:
You want my new language DWIW (Do What I Want) which is due for
release Real Soon Now (just after I get my flying car and fusion
power becomes commercially viable).

Well. What would be wrong with a hypothetical compiler »cc«, so that:

echo 'int main(void){puts("a");}' | cc -Wincludes

gives

line 0: Warning 223: Did you want to include "stdio.h" (puts)?
 
J

Jens

  Well. What would be wrong with a hypothetical compiler »cc«, so that:

echo 'int main(void){puts("a");}' | cc -Wincludes

  gives

line 0: Warning 223: Did you want to include "stdio.h" (puts)?

not very hypothetical, clang does that already. (well puts didn't work
but printf does)

~ 16:52 <23>% echo 'int main(void){printf("a");}' | clang -xc -
<stdin>:1:16: warning: implicitly declaring C library function
'printf' with type
'int (const char *, ...)'
int main(void){printf("a");}
^
<stdin>:1:16: note: please include the header <stdio.h> or explicitly
provide a
declaration for 'printf'
1 warning generated.
 
B

Ben Bacarisse

Well. What would be wrong with a hypothetical compiler »cc«, so that:

echo 'int main(void){puts("a");}' | cc -Wincludes

gives

line 0: Warning 223: Did you want to include "stdio.h" (puts)?

That's not hard:

$ cat x.c
int main(void)
{
puts("a");
my_own_function();
pthread_mutex_lock();
return 0;
}

$ ./inc x.c
x.c: In function ‘main’:
x.c:3: warning: implicit declaration of function ‘puts’
Did you forget to #include <stdio.h>?
x.c:4: warning: implicit declaration of function ‘my_own_function’
x.c:5: warning: implicit declaration of function ‘pthread_mutex_lock’
Did you forget to #include <pthread.h>?

$ cat inc
#!/bin/bash
gcc -std=c99 -pedantic -c "$1" 2>&1 | \
while read W; do
printf "%s\n" "$W"
case "$W" in
*implicit\ declaration*)
F="${W#*‘}"
H="$(man 3 ${F%’} 2>/dev/null | grep '#include ')"
[ -n "$H" ] && printf "Did you forget to %s %s?\n" $H
;;
esac
done

but I am quite happy with just looking up a manual page.
 
K

Keith Thompson

Kenneth Brody said:
And which programming languages do not require that you look up how to
use a feature when you can't remember how it works?

The ones with no documentation, of course.
 
B

Bartc

Kenneth Brody said:
And which programming languages do not require that you look up how to use
a feature when you can't remember how it works?

This is nothing to do with how to use a feature. There're plenty of C
runtime functions that I know perfectly well how to use, but can never
remember exactly which header is needed.

Or I'm adding a bit of code, say using strlen(), and it says "no prototype
for strlen()" or something. it interrupts my concentration.

Or I'm pasting a fragment of code from elsewhere, which uses standard
library features that need a header not yet added to this module. In that
case I don't need or want to know how the feature works, but am forced to
look it up, or try and guess from the other module's list of includes, which
one might be pertinent.

Or I'm removing a piece of code, and I have to maintain, in my mind, a count
of how many references there are to the contents of each header. When the
reference count reaches 0, I have to remove that header.

Leaving it in is usually harmless, but in that case, why not just declare
everything anyway? I'm not too familiar with other languages, other than my
own, but I'd say that basic built-in stuff does not need declaring (by
mechanisms such as include and import) as much as it does in C.

(My own C-like language, it does use one header that declares all the basic
stuff, but the header is automatically included by the compilation process,
so never needs to included explicity in the module.)

So like I said, it's an annoyance than an all-inclusive header file is not
standardised.
 
E

Eric Sosman

And which programming languages do not require that you look up how to
use a feature when you can't remember how it works?

APL. Since nobody can read it, nobody will detect any mistake
you may have made.
 
B

Bartc

... an annoyance than an all-inclusive header file is not standardised.

I think the C library stuff has just been split into too many headers, I
think around 25 files.

If this figure was 250 instead (or every standard function needed it's own
include), that would clearly be impossible (even though all you have to do
is read the docs...)

25 files is just workable, but 1 file would be better. (0 files would be
even better of course!)

This would have been fine 40 years ago but now the few thousand lines of
declarations shouldn't present any particular problems.
 
J

James Kuyper

This is nothing to do with how to use a feature. There're plenty of C
runtime functions that I know perfectly well how to use, but can never
remember exactly which header is needed.

Inserting a #include for the proper header IS part of using those
functions; if you can't remember which one that is, you have less than
perfect knowledge of how to use it. This is no big deal; I've been using
C for more than 3 decades now, and I still frequently check a man page
to remind me which header is required.

I'm not opposed to reducing the number of standard headers needed; that
number was clearly influenced by the fact that, when the library was
first being developed, unnecessarily #including even just a few more
definitions than needed could significantly slow a compilation. That's
much less of an issue now, though it hasn't disappeared completely: as
computers and compilers have gotten more powerful, headers have gotten
longer and more complex. However, the optimum size of a header has
definitely increased substantially, possibly by orders of magnitude.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top