What should be added to C

Frank Adams franka at mmintl.UUCP
Tue Jun 17 13:57:54 AEST 1986


In article <779 at steinmetz.UUCP> davidsen at kbsvax.UUCP (Davidsen) writes:
>I resisted commenting on the original or followup of this, but I can't
>resist on this round!
>
~> Min and max operators.
>
>As for "most but not all C operators are", please state which binary
>operator is not allowed to be used with assignment.

The original statement was indeed ambiguous.  I clarified what I meant in my
reply.  I see no reason for sarcastic interjections.

Binary operators which cannot be used with assignment are "<", ">", "==",
"<=", ">=", "!=", "&&", and "||".

~> An andif clause for if statements.

>>This is equivalent to:
>>
>>   if (!(A)) goto _Z;
>>   X
>>   if (B) {
>>     Y
>>   } else {
>>_Z:
>>     Z
>>   }
>
>*you* might do that, but most people would nest the "if (B)" after the
>"if (A)".
>
>  if (A) {
>    X
>    if (B) {
>      Y
>    }
>  } else {
>    Z
>  }

This is *not* the same.  For andif, the else clause is taken if either
condition fails.

Incidently, I did say that that is how I would *write* the equivalent
structure in C.  It is an attempt to show relatively directly what flow of
control is desired -- but I never jump into a block from outside it.

There are in fact a variety of ways to get the effect of this control
structure, none wholly satisfactory.  These include duplicating the code
"Z", various arrangements with boolean variables, and duplicating the
evaluation of the conditions "A" and "B".  I use various ones, depending
on the particular case.  The issue of how to represent this structure in
existing languages was beaten to death in net.lang not long ago; let's not
repeat it the discussion here.

~>A typeof operator, similar to sizeof.
>
>I mentioned this to a number of people at the X3J11 meeting in Seattle.
>It sounds neat, but is really pretty esoteric. Nobody could think of a
>really great use for it, and trivial uses don't justify a change to the
>language.

There are, I think, lots of useful macros which would be possible with this.

#define allocate(p) (p) = (typeof *(p))(malloc(sizeof *(p))

for example.  There are no major uses except in macros; but I think those
uses justify the feature.

~>continue statements in switches to mean that the next label should be
~>fallen through to.

I was trying to save adding a new keyword.  On further consideration, the
compatibility problem of changing the meaning of continue in this context
is more serious.  So consider the proposal amended to use some other keyword.
Possibilities which occur to me are "nobreak", "proceed", "fall through".
I'm open to suggestions.

~> Elimination of the eight-character truncation of internal variable names
>
>It is obvious that you haven't read the standard.

As with many other people, I do not find it worth my while to spend the time
and money (especially the former) to get a copy of the proposed standard
which is many months out of date.

>The new length is 31 characters for internal names.

This is perfectly adequate.

>I believe the original posting also mentioned complex as a type,
>currently in C++, desirable in C.

No, someone else brought it up later.

>Larry Rossler suggested that in an
>early X3J11 meeting, but the response was underwhelming from most of
>the committee. I personally feel that (a) this would get FORTRAN out of
>my life at last, and (b) no one can convince me that it's too big,
>since I had complex in FORTRAN on my CP/M machine with a total of 48k.

In many ways, I would rather have the ability to define how operators are to
be interpreted for defined (structure) types.  This would be significantly
harder to implement, but it deals with a larger class of problems, and in
many ways seems to me to be more in keeping with the C philosophy.

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