Function header files

On Feb 17, 3:56*pm, David Resnick <lndresn...@gmail.com> wrote:
>
> 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.

On Feb 17, 9:20*am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> 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

On 02/18/11 03:05 AM, David Resnick wrote:
> On Feb 16, 3:12 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>> On 02/17/11 05:07 AM, David Resnick wrote:
>
>>> 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.
>
> 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.

--
Ian Collins

On Feb 17, 1:53*pm, Ian Collins <ian-n...@hotmail.com> wrote:
> 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
#include <assert.h>
>
> > 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.

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

Le 17/02/11 19:53, Ian Collins a écrit :
> On 02/18/11 03:05 AM, David Resnick wrote:
>> On Feb 16, 3:12 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>>> On 02/17/11 05:07 AM, David Resnick wrote:
>>
>>>> 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.
>>
>> 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.
>

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

jacob navia <jacob@spamsink.net> writes:
> 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.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 02/18/11 08:07 AM, David Resnick wrote:
> On Feb 17, 1:53 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>> 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>

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

--
Ian Collins

On 2/16/11 4:43 AM, Malcolm McLean wrote:
> He's got malloc.h in there as well, which is another DOS-ism.

On old versions of Unix (SCO Xenix vintage), <malloc.h> provided extra
functions over and above the 4 hallowed in the (later) C standard that
allowed you to tune the memory allocation algorithm a bit, and find out
about the memory used, and so on. It also reliably declared malloc() et
al in the days before there was <stdlib.h> to use.

Once the standard library became available, the main use for <malloc.h>
was obsolete.

-=JL=-

On 2/16/11 5:10 AM, pete wrote:
> Also, <stdio.h> is insufficient for using
> any of the stdio functions which have names starting
> with the letter 'v', such as vfprintf.
>
> <stdarg.h> must be #included too, to use those functions.

That is correct, but requires careful thinking to understand why it is
correct (my first reaction was "it is wrong").

The v-functions are declared in <stdio.h> and do not require you to
include <stdarg.h> before the functions are declared.

However, you cannot use those functions - the v-functions - unless you
have a va_list, and you can only get a definition of va_list through
<stdarg.h>.

So, the key word in the last sentence is 'use'.