u-beasth%peruvian.utah.edu@cs.utah.edu (Bryant Eastham) (04/16/91)
In an attempt to understand the attitudes of some people on the net I
submit the following:
NEWS FLASH
----------
The QWOP Corporation announced yesterday that it will NOT support certain
constructs of the ANSI C Standard in any of its new compilers. In the
words of J.W. Antistandard, QWOP's President, "the constructs are unneeded,
and can easily be kludged with other constructs that we do support." He
continued by urging, in the name of portability, that computer programmers
throughout the civilized world discontinue the use of these unsupported
constructs, or at very least bracket them with #if and #endif so that they
can easily be enabled or disabled at compile-time.
To prevent needless flames, the above is a joke - but seems to mirror
the attitudes of some people that have recently posted to the net in regards
to nested includes.
I believe that "ANSI C" is a standard. A compiler is just a program! When
-----------------------------
the standard says that system headers may be included multiple times then
write code as though they can. If you then find a program (read: compiler)
that can't handle the nested includes, then I suggest:
1) Fix the program (read: compiler). Use your ingenuity. If the
system-supplied headers cannot be included multiple times then
shadow them with other headers (that you will write) that include
adaquate protection and include the system-supplied headers. That
is why compilers give us smart programmers control over directory
search paths.
2) Write to or otherwise contact the author(s) of the "broken"
program (read: compiler). Complain to them. Get them to conform
to the standard just as you are trying to conform to it. With few
exceptions the author(s) or the program (compiler) are in it to
make money and your input will have a good chance or influencing
them. If they are unwilling to change then you may really consider
junking their program (read: compiler) and using one that will keep
up with current trends (and standards).
Another argument against using nested includes is the added time needed
to compile. Using this logic they should also be using 1 character
identifiers to speed up symbol table lookup during compilation, and I
don't want to see a single floating point operation in their code unless
the target machine has a coprocessor to speed up these time consuming
operations.
The point is, data abstraction, which is made possible by nesting includes,
is an accepted and desirable technique and a real programmer will be more
concerned about using valid techniques than having to wait a few minutes
more to compile his code. Future generations will call him blessed!
LET THE FLAMES BEGIN!
Does anyone have an asbestos suit I could borrow?
Bryant Eastham
A Programmer who would die without nested includes.
Long Live makedepend and gcc.brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/17/91)
In article <1991Apr16.154655.14204@hellgate.utah.edu> u-beasth%peruvian.utah.edu@cs.utah.edu (Bryant Eastham) writes: > When > the standard says that system headers may be included multiple times then > write code as though they can. For code that you write once and use in-house, do whatever works. For code that you distribute or plan to port to future systems, you should never make an assumption like that. Chances are your code won't compile on two different systems. Which is better, some work on your part now to make your application portable, or thousands of hours of work on the part of others in the future to do the job for you? I fully support properly protected #include files. I even sent out a simple tool recently---comp.sources.misc/volume17/quacko---which tests that your .h file not only correctly reflects the symbols in your .o file, but can be included both once and twice without preparation. But I'm not going to pretend that vendors care about #include file quality, and I'm not going to (intentionally) write code that includes system headers twice. ---Dan
morse@hatteras.cs.unc.edu (Bryan Morse) (04/17/91)
In article <28721:Apr1701:15:3791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1991Apr16.154655.14204@hellgate.utah.edu> u-beasth%peruvian.utah.edu@cs.utah.edu (Bryant Eastham) writes: >> When >> the standard says that system headers may be included multiple times then >> write code as though they can. > >For code that you distribute or plan to port to future systems, you >should never make an assumption like that. Then why even have a standard in the first place? The general opinion has often surfaced here that, "Well, it may be in the standard, but if you do it it won't be portable." Huh??? I realize that it takes time for a standard to emerge and that compliance is optional, but does that mean we should continue to write every C program according to K&R Edition 1, First printing? Never use enums, never use prototypes, never use voids, never return structures... -- Bryan Morse University of North Carolina at Chapel Hill morse@cs.unc.edu Department of Computer Science
ts@cup.portal.com (Tim W Smith) (04/18/91)
I try to follow two rules with my include files: 1. An include file shall not cause harm by being included multiple times. 2. An include file shall include all other include files needed to make it work, unless that conflicts with the first rules. Rule #2 means that if you want, say, the structure definition for a user area, you say #include <sys/user.h> You do NOT have to say: #include <sys/types.h> #include <sys/param.h> #include <sys/config.h> #include <sys/proc.h> #include <sys/dir.h> #include <sys/mmu.h> #include <sys/buf.h> #include <sys/user.h> Sometimes this can get ugly, though. I had a pair of include files that happened to need parts of each other. What needed to happen at compile time was that the compiler should see the first part of file A, then file B, and then the rest of file A. Each file ended up including the other, with appropriate conditionals to make sure the right thing happened, but it was not pretty. Tim Smith
gwyn@smoke.brl.mil (Doug Gwyn) (04/18/91)
In article <3264@borg.cs.unc.edu> morse@hatteras.cs.unc.edu (Bryan Morse) writes: >The general opinion has often surfaced here that, "Well, it may be in the >standard, but if you do it it won't be portable." Huh??? I realize that >it takes time for a standard to emerge and that compliance is optional, >but does that mean we should continue to write every C program according >to K&R Edition 1, First printing? Never use enums, never use prototypes, >never use voids, never return structures... Certainly I am a proponent of C standard conformance, and some day we may be able to rely on that for application source portability. However, it is a fact of life that currently many C implementations are far from standard conforming. I've found that the implementations I personally have to deal with fall into two categories (with small glitches due to compiler bugs etc.): standard conforming, or else based on UNIX PCC. Thus a fairly minor amount of kludgery in the application source code can attain much wider portability of the application than limiting it to either environment alone. As part of this accommodation of non-standard implementations, one often needs to avoid assuming full ANSI C behavior of the implementation; often this practice does not do major violence to the source code.