What should be added to C

Frank Adams franka at mmintl.UUCP
Fri May 23 12:03:38 AEST 1986


In article <5498 at alice.uUCp> ark at alice.UUCP writes:
>Frank Adams says:
>
>> As has been noted, one should use restraint in adding new features to a
>> language.  What follows is a list of the features I would support adding to
>> the *next* version of C (after the current standard is complete).
>
>OK, let's see his examples of "restraint:"
>
>> o Min and max operators.  These would get used all over the place.  These
>> should be usable to the left of the assignment operator, as most but not all
>> C operators are.
>
>What would it mean to use these on the left of an assignment,
>and why would you want to use it?

It would mean what it usually means.  If "\/" is the minimum operator, then
"a \/= b" would mean "a = a \/ b".  I find it hard to believe that anyone
with any programming experience would need to ask why you would want to use
it.

>> o An andif clause for if statements.
>
>What does it do and how would you use it?

You would write:

  if (A) {
    X
  } andif (B) {
    Y
  } else {
    Z
  }

This is equivalent to:

   if (!(A)) goto _Z;
   X
   if (B) {
     Y
   } else {
_Z:
     Z
   }

>> o The ability to define multi-line pre-processor macros, using #begdef and
>> #enddef statements.  #if and other conditionals in the body of the
>> definition would be evaluated when the macro was not interpreted, not when
>> it is encountered.
>
>Why would you want to use it?

To write more sophisticated macros.  For example, one could write a copy
macro which would invoke strcpy in most cases, but a word copy routine to
copy an array of structures whose size is a multiple of a word.  Such a
macro would be machine dependant -- this is exactly the reason for making it
a macro, instead of hard coding the calls.

>> o A typeof operator, similar to sizeof.
>
>What would its value be?  Why would you want to use it?

"typeof(x)" would be a type, which is the type that x was declared as.  This
is for use primarily in macros.

>> o := as a synonym for =.  Compilers could have an option to permit := only.
>
>Why bother?

Confusing "=" and "==" in if statements is a common mistake.  If "=" is not
a legal operator, this error becomes very rare.

>> o Permit a continue statement in switch, meaning that the next label should
>> be fallen through to.  Compilers and/or lint could produce when a program
>> falls through without a continue statement.
>
>A continue statement is already legal in a switch, as long as that
>switch is enclosed in a for or while.  It means go on to the next
>iteration of the enclosing loop.  Are you proposing to change this?

Yes.

>> o Any sort of multi-level break statement.  There is no syntacticly clean
>> way of adding this to C.
>
>C already has a multi-level break statement.  It's spelled "goto."
>Putting a goto in a costume doesn't disguise it.

You weren't reading very carefully.  This was on my list of things which
should *not* be added.

>> o Elimination of the eight-character truncation of internal variable names
>> done by some compilers.  (This may be in the current spec; I haven't read
>> that document.)  The entire length of a variable name should be significant.
>
>Most compilers do this already.

So let's make it part of the standard, and those of us who like to write
portable code can start using it.

>The trouble with adding new features to C is that there is a very
>strong incentive not to use them.  After all, any program that
>uses some new feature is only going to run on machines that support
>that feature.  I don't think I'm going to be using only one compiler
>for the rest of my life and would like to avoid changing my code
>every time the environment hiccups.

This is the whole point of having a standard.  It gives you some assurance
that compilers which use the features will be available.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108



More information about the Comp.lang.c mailing list