[comp.lang.c] Programming Style

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.