Function header files

[ImpalerCore]

I'd advise against using this site unless you are working in C++.
It works for common C functions but fails for a lot of newer C99
functions.

Hi,
I am a student of C/C++.

I think it does pretty decent for the core standard library, but I
agree that its C99 documentation is practically non-existent.

I refer people to this website as a supplemental resource who are
learning C. The books I have don't reference in detail most of the
C99 stuff (I don't own any new C teaching books that talk about C99
though they are probably out there). If you advise against the site,
do you have an alternative that's better?

Best regards,
John D.

 

[Ian Collins]

I'm not sure it is bad "style", but it can certainly cause performance
issues in a large scale build to access/read/parse all the unneeded
header files, particularly if they aren't on a local filesystem.

The opposite may also be true; if your compiler supports pre-compiled
headers, it can speed things up. Unless you have an awful lot of
headers and not a lot of RAM, the OS will probably have cached them all
on first read, so remote files doesn't usually have too big an impact.

To OP, I'd personally just learn which standard functions go with
which headers.
May take a while, but the C standard library isn't THAT huge...

Agreed.

 

[Ben Bacarisse]

I think it does pretty decent for the core standard library, but I
agree that its C99 documentation is practically non-existent.

I refer people to this website as a supplemental resource who are
learning C. The books I have don't reference in detail most of the
C99 stuff (I don't own any new C teaching books that talk about C99
though they are probably out there). If you advise against the site,
do you have an alternative that's better?

I'd advise using local documentation -- from an IDE or manual pages.
Since there are lots of manual page websites, I suppose I am indirectly
recommending them. For example:

http://www.linuxmanpages.com/

Using the text input box + "3. Subroutines" drop-down does a reasonable
job.

For just standard C, the draft PDF (link posted elsewhere) is excellent
since, at least in my PDF reader, I can type a partial function name and
that section can be viewed immediately. A different reader might make
it less useful, though.

 

[Ike Naar]

I am a student of C/C++. One of the mistakes I often make is
forgetting to include the appropriate header files for the standard
functions I use. Is there an easy way (a website?) to find out where
a certain standard function is prototyped in? I can find answers via
google search or MSDN library, but it's more time consuming than I'd
prefer. Ideally, I would prefer to just go to a website, type in the
name of the function in a search box and find out what header file I
should include and how it is defined. Thanks for your help!

You might try the Dinkumware site:

http://www.dinkumware.com

 

[Malcolm McLean]

If you're going to use that approach, perhaps it would be better to have
"stdheader.h" include just the standard headers; if you're using
features from <conio.h> it might be better to emphasize that by
including it directly in your source file.

(Personally I've never done that kind of thing, and it *feels* like
poor style, but I'm not sure I can articulate why.)

It's the job of a standards body.

Imagine you are writing a few string functions - strcount(), let's
say, which counts all instances of ch in str.

Naturally such a valuable and reuseable function should be avialable
to others, so it's
stdheader.h
strcount.h
strcount.c

Now someone else writes a block allocator.

stdhdr.h
blockmalloc.h
blockmalloc.c

Now someone else wants to write a suffix tree. it calls both strcount
and the block allocator.

stdheader.h
strcount.h
strcount.c
stdhdr.h
blockmalloc.h
blockmalloc.c
stdheader.h
suffixtree.h
suffixtree.c

See the problem?

 

[David Resnick]

It's the job of a standards body.

Imagine you are writing a few string functions - strcount(), let's
say, which counts all instances of ch in str.

Naturally such a valuable and reuseable function should be avialable
to others, so it's
stdheader.h
strcount.h
strcount.c

Now someone else writes a block allocator.

stdhdr.h
blockmalloc.h
blockmalloc.c

Now someone else wants to write a suffix tree. it calls both strcount
and the block allocator.

stdheader.h
strcount.h
strcount.c
stdhdr.h
blockmalloc.h
blockmalloc.c
stdheader.h
suffixtree.h
suffixtree.c

See the problem?

Actually, I see no problems. Please explain your point further.
If their implementations of library functions require them to use
other library functions, that doesn't impact the interfaces. It is
only if they want to expose in their interface something defined
in another header that there is an issue. Or perhaps I'm missing
your point.

-David

 

[David Resnick]

On 02/17/11 05:07 AM, David Resnick wrote:

The opposite may also be true; if your compiler supports pre-compiled
headers, it can speed things up.  Unless you have an awful lot of
headers and not a lot of RAM, the OS will probably have cached them all
on first read, so remote files doesn't usually have too big an impact.

I can't see how including a header that includes all system headers
in every file could ever speed things up relative to the selective
inclusion in each file of exactly what is needed. Why would this be?
I'm a bit murky on pre-compiled headers, haven't dealt with them,
but do they work if they have anything that depends on the compile
time
defines that riddle many system headers?

Mostly moot for system headers I agree, as they are mostly on the
local filesystem, etc. None of the regular code I use is on the
local filesystem (we use Clearcase, which uses a virtual file
system with the files residing elsewhere on a view server).
Certainly
for normal header files, it is a cost to include files you don't care
about, as the time to rebuild a large code base is significant and
unneeded depencencies make it worse...

-David

 

[Malcolm McLean]

Actually, I see no problems.  Please explain your point further.
If their implementations of library functions require them to use
other library functions, that doesn't impact the interfaces.  It is
only if they want to expose in their interface something defined
in another header that there is an issue.  Or perhaps I'm missing
your point.

If stdheader.h is defined by Fred, Jim, Bert and Harry, rather than by
ANSI, you'll get a proliferation of such headers. Fred will call his
stdhdr.h, Jim stdheader.h. Bert will add definitions for min and max
because his version of stdlib.h contains them and he doesn't want to
break code compiled on a different system. Harry will mistakenly
include malloc.h then release version 2 in which this error is
corrected.
It'll turn into an awful headache, having to go through and compare
different standard headers to see what they contain, because something
somewhere might break.

 

[David Resnick]

If stdheader.h is defined by Fred, Jim, Bert and Harry, rather than by
ANSI, you'll get a proliferation of such headers. Fred will call his
stdhdr.h, Jim stdheader.h. Bert will add definitions for min and max
because his version of stdlib.h contains them and he doesn't want to
break code compiled on a different system. Harry will mistakenly
include malloc.h then release version 2 in which this error is
corrected.
It'll turn into an awful headache, having to go through and compare
different standard headers to see what they contain, because something
somewhere might break.

I see, makes some sense. While I disagree with the idea that
it is useful to do a catch-all system header, I don't see this
as an objection to using it in a specific project. You need
to get people to agree to all sorts of things in a coordinated
project, don't see this as an insurmountable difficulty. If you
had to merge two projects that do it differently, there is no
real cost to including both, as the include guards will prevent much
from happening on duplicate includes of headers.

-David

 

[Ian Collins]

I can't see how including a header that includes all system headers
in every file could ever speed things up relative to the selective
inclusion in each file of exactly what is needed. Why would this be?
I'm a bit murky on pre-compiled headers, haven't dealt with them,
but do they work if they have anything that depends on the compile
time defines that riddle many system headers?

All of the PCH systems I've used rely on the order of header inclusion
being the same in each translation unit, so putting all the system
headers in one file guarantees this. The compiler will cache the result
of parsing those headers and used the cached data whenever that sequence
of include files is encountered.

Mostly moot for system headers I agree, as they are mostly on the
local filesystem, etc. None of the regular code I use is on the
local filesystem (we use Clearcase, which uses a virtual file
system with the files residing elsewhere on a view server).
Certainly
for normal header files, it is a cost to include files you don't care
about, as the time to rebuild a large code base is significant and
unneeded depencencies make it worse...

But the files will be cached on the local host.

 

[David Resnick]

On 02/18/11 03:05 AM, David Resnick wrote:
All of the PCH systems I've used rely on the order of header inclusion
being the same in each translation unit, so putting all the system
headers in one file guarantees this.  The compiler will cache the result
of parsing those headers and used the cached data whenever that sequence
of include files is encountered.

Hmmm, but how does that deal with the fact that a header is often
"dynamic" in that
different patterns of macro definitions may result in a different
parsing?
As in the common:
#define NDEBUG
#include <assert.h>

vs

But the files will be cached on the local host.

I'm not sure how much caching is done in mvfs, but I'd guess that each
read of a file in clearcase at least needs some minimal check of the
server to see if the file has changed since last accessed.

But my bigger issue which basically only applies to non-standard
library files isn't fetching the files. It is the build
dependencies. In the worst case, if your paradigm is to include every
known header in every source file to avoid having to figure out which
really need to be included, anyone touching any header would trigger a
global rebuild. In my project, that would be some thousands of C++
files that take some hours to rebuild, irritating when it happens in
the middle of the day.

-David

 

[jacob navia]

Le 17/02/11 19:53, Ian Collins a écrit :

All of the PCH systems I've used rely on the order of header inclusion
being the same in each translation unit, so putting all the system
headers in one file guarantees this. The compiler will cache the result
of parsing those headers and used the cached data whenever that sequence
of include files is encountered.


But the files will be cached on the local host.

Yes, and the cost of inclusion can be avoided with
#pragma once
or the old
#ifndef __STDHEADERS_H
#define __STDHEADERS_H
....
#endif

 

[Keith Thompson]

Le 17/02/11 19:53, Ian Collins a ecrit : [...]

But the files will be cached on the local host.

Yes, and the cost of inclusion can be avoided with
#pragma once

Which is of course non-standard, but it's widely implemented.
Implementing it correctly in the presence of, for example, symbolic
links that refer to the same file can be tricky.

or the old
#ifndef __STDHEADERS_H
#define __STDHEADERS_H
...
#endif

Which still incurs the cost of scanning the entire file (unless the
compiler specifically optimizes this case, as I understand gcc does).

Note that the identifier __STDHEADERS_H is reserved to the
implementation.

 

[Ian Collins]

Hmmm, but how does that deal with the fact that a header is often
"dynamic" in that
different patterns of macro definitions may result in a different
parsing?
As in the common:
#define NDEBUG
#include<assert.h>

I haven't done any test, but I'd expect it to be conservative and
consider the inclusion different.