🚀 go-pugleaf

[cc'd to poster]


With <4gqe8u$pn7@solutions.solon.com>,
it seems Pieter Hintjens (pahint@eunet.be) sez:

+ I am building the ultimate Universal Header File.  :-)
+ This is a tool to make cross-platform programming in C
+ easier.  Basically, all 'common' header files are put
+ in the uUHF, instead of in each program.  By 'common',
+ I mean: all ANSI C header files, plus file i/o, socket
+ i/o, and anything else that is useful.

[snip 350-line header]

I did something similar on a smaller scale.  Compilation of even
the small programs took forever.  I went back and commented out
the #include statements which I knew weren't being used.  The
speedup was *significant*, and I say that running Digital Unix on
a DEC Alpha 4000.

What I had been seeing -- but not reading -- for years finally
sank in after that experience:  more often than not, the most
expensive (timewise) step in compilation is processing of header
files.  What you have in mind may be great for those platforms
which support preprocessed header files, with the result of the
preprocessing being stored in some intermediate state in a local
directory with the rest of the source, but for typical platforms
which process the same file again and again -- sorry, but I'd
hate to use anything that massive.

Just my two timeslices.


Luck++;
Phil

-- 
#include<std/disclaimer.h>               The gods do not protect fools. Fools
finger pedwards@gamma.cs.wright.edu      are protected by more capable fools.
email pedwards@valhalla.cs.wright.edu                            -Larry Niven

Phil Edwards (pedwards@valhalla.cs.wright.edu) wrote:
: it seems Pieter Hintjens (pahint@eunet.be) sez:
: + I am building the ultimate Universal Header File.  :-)

: I did something similar on a smaller scale.  Compilation of even
: the small programs took forever.  I went back and commented out
: the #include statements which I knew weren't being used.  The
: speedup was *significant*, and I say that running Digital Unix on
: a DEC Alpha 4000.

: What I had been seeing -- but not reading -- for years finally
: sank in after that experience:  more often than not, the most
: expensive (timewise) step in compilation is processing of header
: files.  What you have in mind may be great for those platforms
: which support preprocessed header files, with the result of the
: preprocessing being stored in some intermediate state in a local
: directory with the rest of the source, but for typical platforms
: which process the same file again and again -- sorry, but I'd
: hate to use anything that massive.

When I started with this 'universal header file' the motivation was
to let me edit and compile my code on a PC, with Borland's fast tools
and their pop-up help.  Once I had a 'clean' source I could recompile
and test on the UNIX.

This still stands.  On my cheap pentium, Turbo-C is *fast*.  Even
with all the include's.  The total time I spend compiling is much
less than if I worked only on a UNIX, with a many fewer include's.

Sure, I can't really test my code, but I tyep baldy^H^H^H^H^H^Htype
badly, and I save a lot of time by editing and proof-compiling on
the platform of choice.

Okay, point taken about including masses of files: I am making the
UIF smarter, so that you can tune it with a few #define's at the
start of your program.

Anyone interested in following this project, drop me a line. 
--
Pieter A. Hintjens

Pieter Hintjens (pahint@eunet.be) wrote:
[snip]
: When I started with this 'universal header file' the motivation was
: to let me edit and compile my code on a PC, with Borland's fast tools
: and their pop-up help.  Once I had a 'clean' source I could recompile
: and test on the UNIX.

: This still stands.  On my cheap pentium, Turbo-C is *fast*.  Even
: with all the include's.  The total time I spend compiling is much
: less than if I worked only on a UNIX, with a many fewer include's.

: Sure, I can't really test my code, but I tyep baldy^H^H^H^H^H^Htype
: badly, and I save a lot of time by editing and proof-compiling on
: the platform of choice.

: Okay, point taken about including masses of files: I am making the
: UIF smarter, so that you can tune it with a few #define's at the
: start of your program.

: Anyone interested in following this project, drop me a line. 
: --
: Pieter A. Hintjens

With almost any well thought-out project, there's usually an associated
rationale (take the C Standard for instance).  However, I really don't
see any point in creating a "universal header file".  It's like the
physics profs drill into our heads "you can't get something for nothing".
Kind of a conservation of CPU cycles principle :)

Anyway... if you want to do something useful, write a piece of code that
scans C source modules and determines what headers should be included and
add those to the source.  Otherwise, you'll end up with a bunch of useless
clutter with .h as its file extension.  (However, such a product might
get you hired by Microsoft :)

Greg
--
Greg Bacon <gbacon@cs.uah.edu>
University of Alabama in Huntsville
CS Department Systems Support Team

pahint@eunet.be (Pieter Hintjens) writes:

>Phil Edwards (pedwards@valhalla.cs.wright.edu) wrote:
>: it seems Pieter Hintjens (pahint@eunet.be) sez:
>: + I am building the ultimate Universal Header File.  :-)

[...]
>Okay, point taken about including masses of files: I am making the
>UIF smarter, so that you can tune it with a few #define's at the
>start of your program.

But that's absolutely counter-useful! Where's the real gain if you have
to write 

#define WANT_STDIO
#define WANT_LOCAL_SOMETHING
#include <uUHF.h>

instead of

#include <stdio.h>
#include <local_something.h>

(And you would actually *have* to use such a method of defining *all*
the necessary WANT's, or equivalently some DONT_WANT's, to keep at least
a bit of your available namespace free for use by the program you're
writing)

Anyway, IMHO such an uUHF would be such a big waste of name space as
to render it a real nuisance, and lose all it's possible benefits
at once.

Hans-Bernhard Broeker (Aachen, Germany)

Hans-Bernhard Broeker wrote:
> But that's absolutely counter-useful! Where's the real gain if you have
> to write
> 
> #define WANT_STDIO
> #define WANT_LOCAL_SOMETHING
> #include <uUHF.h>
> 
> instead of
> 
> #include <stdio.h>
> #include <local_something.h>
> 

I missed the start of this, so I may have the wrong end of the stick, but 
I think that the intention would be to replace code like:

#if defined(SOME_SYSTEM)
#include <malloc.h>
#elif defined(SOME_OTHER_SYSTEM)
#include <alloc.h>
#elif defined(YET_ANOTHER_SYSTEM)
#include <memory.h>
#else
#include <stdlib.h>
#endif

#if defined(MSDOS)
#include <sys\\stat.h>
#elif defined(VMS)
#include <whatever file spec needed for VMS>
#else
#include <sys/stat.h>
#endif

with code like this:

#define INCLUDE_MALLOC
#define INCLUDE_STAT
#include <uUHF.h>

There are lots of cases where different systems need different include 
files.


-- 
#####################################################################
Michael Smith                                       msmith@mpx.com.au
Emmenjay Consulting                 http://www.hutch.com.au/~emmenjay
#####################################################################

(My apologies for the large quote, but the example was pretty hard to
trim....)

In article <4iermd$apc@solutions.solon.com> Michael Smith <msmith@mpx.com.au>
writes:
>I missed the start of this, so I may have the wrong end of the stick, but 
>I think that the intention would be to replace code like:
>
>#if defined(SOME_SYSTEM)
>#include <malloc.h>
>#elif defined(SOME_OTHER_SYSTEM)
>#include <alloc.h>
>#elif defined(YET_ANOTHER_SYSTEM)
>#include <memory.h>
>#else
>#include <stdlib.h>
>#endif
>
>#if defined(MSDOS)
>#include <sys\\stat.h>
>#elif defined(VMS)
>#include <whatever file spec needed for VMS>
>#else
>#include <sys/stat.h>
>#endif
>
>with code like this:
>
>#define INCLUDE_MALLOC
>#define INCLUDE_STAT
>#include <uUHF.h>

I think this is the wrong approach.  These two examples are actually
rather good, because they are also rather different.

Let us consider malloc() first.  If we have a conformant compiler,
<stdlib.h> will be the correct include file, but there are still some
compilers Out There that require the use of `alloc.h' or `memory.h'
or some such.  In this case, it is actually fairly reasonable to want
a simple and direct way to include the correct header.  I would
probably solve this in one of two or three ways:

	- Simply #include <stdlib.h>, and require that it be
	  correct (by fixing or replacing the implementation if
	  necessary).

	- Write my own module that implements memory allocation;
	  put any gross #ifdef'ing into it, and use `myalloc()'
	  everywhere.  This is particularly sensible if you want to
	  use a `void *' allocator (some of the systems return
	  `char *') and/or have a standard out-of-memory error.

	- Use a macro to define the name of the correct header, and
	  `#include MALLOC_H'.

The second case is harder, if less subtle (e.g., for malloc we had to
think about pre-ANSI implementations).  In this case, there is no
guarantee that there *is* a `stat.h' of *any* kind.  Here, I would
relegate the inclusion of a stat.h (or equivalent) to a port-specific
module, and hide access to the `struct stat' (or equivalent) behind
soem sort of interface.  Then, when the application is ported to an
ancient IBM O/S, we simply (hah!) need to write a module that gleans
the desired information from the various FCBs.  The application may
even become usable on a system that lacks files entirely (and therefore
has no equivalent of any stat structure), though obviously this would
depend on the application itself.

Writing portable code is difficult, but I think that attempting a
universal header file is the wrong approach in most, if not all,
cases.  The right approach is to pick a set of standards you will
require (such as ANSI or POSIX), define your own abstractions for
what you need from the system, and write everything *not* provided
in those standards using those abstractions.  Perhaps (e.g., for
efficiency) some or most of those will simply be macros, and only
time and porting can prove which abstractions were sufficiently
abstract -- but there is no way that (for instance) you are going
to make a TCP application work on a machine that has no networking
code of any kind, so there is no point in `universalizing' the
header file for TCP on machines that do not support it.
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA	Domain:	torek@bsdi.com	+1 510 234 3167

Chris Torek wrote:
> 
>         - Simply #include <stdlib.h>, and require that it be
>           correct (by fixing or replacing the implementation if
>           necessary).

Can't agree with that.  Changing system headers is a recipe for 
maintenance disasters.

> 
>         - Write my own module that implements memory allocation;
>           put any gross #ifdef'ing into it, and use `myalloc()'
>           everywhere.  This is particularly sensible if you want to
>           use a `void *' allocator (some of the systems return
>           `char *') and/or have a standard out-of-memory error.
> 
>         - Use a macro to define the name of the correct header, and
>           `#include MALLOC_H'.

No real objection to either of these.


Let me clear up one thing.  I was not saying that I agreed with the 
universal header concept, simply explaining what it was.  An earlier 
poster appeared to have misunderstood.

My preferred method is to encapsulate particular subsystems where 
portability is an issue.  I have been known to use a "sysdefs.h" or 
similar where system specific macros were defined, such as the
#define MALLOC_H <stdlib.h> from your example.


-- 
#####################################################################
Michael Smith                                       msmith@mpx.com.au
Emmenjay Consulting                 http://www.hutch.com.au/~emmenjay
#####################################################################

I suggested (as one approach for dealing with broken <stdlib.h> headers):
>>         - Simply #include <stdlib.h>, and require that it be
>>           correct (by fixing or replacing the implementation if
>>           necessary).

In article <4j06k0$7s9@solutions.solon.com> Michael Smith <msmith@mpx.com.au>
writes:
>Can't agree with that.  Changing system headers is a recipe for 
>maintenance disasters.

That depends -- sometimes I am the implementor. :-)

Seriously, though, by `replacing the implementation' I meant
`returning the broken compiler, and buying a correct one from
another vendor'.  This is often possible, and is a good idea since
it exerts the most effective kind of pressure available to the
consumer.

Sometimes the real world interferes with this approach (e.g., when
the vendor has a monopoly on the supply of compilers for the CPU
in question).  In such cases, however, it usually turns out that
broken header files are the least of your worries.  Also, most of
these situations involve writing code that will never be portable
anyway (since, e.g., the 98951J is used entirely differently in
the electric mixer than in the toaster, all to save 3/10ths of a
cent per unit).

>My preferred method is to encapsulate particular subsystems where 
>portability is an issue.

Agreed.
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA	Domain:	torek@bsdi.com	+1 510 234 3167