Thoughts on file organisation

[fnegroni]

Where I have looked at system headers they include other (often private)
headers. The standard does not say that a system header cannot include
another header, it says that it must behave as if it does not include
any of the other headers defined by the standard.

But *why?* is the question.

 

[John Bode]

Building our product on a mere quad core xeon with 4GB ram only takes
a mere 2 hours.

See? Progress!

But then we compile our code on 26 platforms, some are even slower...

But again, how much of that is tokenizing vs. code generation vs.
optimizing vs. linking? I'll bet real money that lexical analysis is
*not* the bottleneck.

 

[Bartc]

Building our product on a mere quad core xeon with 4GB ram only takes
a mere 2 hours.
But then we compile our code on 26 platforms, some are even slower...

In 1989 I was using my own compilers and loaders (I'd eliminated
link-loading), so nothing ever took more than a few seconds, for executables
up to a few 100KB.

Now I use a standard linker but still have never seen anything take that
long.

Just how big are these applications that take 2 hours or 6 hours to compile
and link? What is the bottleneck exactly? Optimisation?

I wouldn't tolerate a 2-minute build let alone 2 hours.

 

[David Tiktin]

David Tiktin wrote, On 29/01/08 23:58:

Where I have looked at system headers they include other (often
private) headers. The standard does not say that a system header
cannot include another header, it says that it must behave as if
it does not include any of the other headers defined by the
standard.

Yes, I had a chance to look at Plauger last night and he does just
that. He has a file called _yvals.h which #defines _NULL and in
standard headers that have to #define NULL he does:

....
#include <_yvals.h>
....
#define NULL _NULL

So Plauger tries to stay DRY. But as fnegroni asks elsethread, why
aren't standard headers allowed to #include other standard headers? Is
it forbidden by the standard? If so, why? This seems especially hard
to understand for stdarg.h since stdio.h has prototypes which need to
include va_list arguments such as vprintf() and va_list is defined in
stdarg.h.

Plauger explains that one of the principle governing the design of the
standard headers is that they be independent of each other (which is
why they don't #include other standard headers). But I can't find the
exact reason *why* this is such an important principle. Can you
explain? Or maybe I should ask in comp.std.c?

Dave

 

[Flash Gordon]

David Tiktin wrote, On 30/01/08 18:26:

Yes, I had a chance to look at Plauger last night and he does just
that. He has a file called _yvals.h which #defines _NULL and in
standard headers that have to #define NULL he does:

...
#include <_yvals.h>
...
#define NULL _NULL

So Plauger tries to stay DRY. But as fnegroni asks elsethread, why
aren't standard headers allowed to #include other standard headers? Is
it forbidden by the standard?

It is forbidden by the standard.

If so, why?

Possibly so that you know for certain which will be defined if you
include a given header rather than having to guess whether it might have
included another header. Of course, the standard could instead have said
things like, "stdio.h includes stddef.h" but that is not the route they
chose.

This seems especially hard
to understand for stdarg.h since stdio.h has prototypes which need to
include va_list arguments such as vprintf() and va_list is defined in
stdarg.h.

Plauger explains that one of the principle governing the design of the
standard headers is that they be independent of each other (which is
why they don't #include other standard headers). But I can't find the
exact reason *why* this is such an important principle. Can you
explain? Or maybe I should ask in comp.std.c?

If it is not documented in the standard or the rationale then comp.std.c
would be the place to ask.

 

[santosh]

In 1989 I was using my own compilers and loaders (I'd eliminated
link-loading), so nothing ever took more than a few seconds, for
executables up to a few 100KB.

Now I use a standard linker but still have never seen anything take
that long.

Just how big are these applications that take 2 hours or 6 hours to
compile and link?

Even compiling the Linux kernel or something like GNU libc takes around
30 minutes and 45 minutes respectively on a Pentium Dual Core 1.6 GHz
with a Gb of RAM.

What is the bottleneck exactly? Optimisation?

That's definitely a factor, which is visible even for a pretty trivial
program. Hard optimisation levels like O3 and above tend to take a lot
of time. Also the so called "high level optimisations" of the Intel
compilers are a real time killer.

I wouldn't tolerate a 2-minute build let alone 2 hours.

There is no choice when compiling "biggies" like Mozilla, KDE etc. Even
on cutting edge machines they tend to take at least a half hour or so.