Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!pwa-b!mmintl!franka From: franka@mmintl.UUCP (Frank Adams) Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <1567@mmintl.UUCP> Date: Mon, 16-Jun-86 23:57:54 EDT Article-I.D.: mmintl.1567 Posted: Mon Jun 16 23:57:54 1986 Date-Received: Thu, 19-Jun-86 03:37:43 EDT References: <1462@mmintl.UUCP> <5498@alice.uUCp> <1497@mmintl.UUCP> <779@steinmetz.UUCP> Reply-To: franka@mmintl.UUCP (Frank Adams) Organization: Multimate International, E. Hartford, CT Lines: 108 In article <779@steinmetz.UUCP> davidsen@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