Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!mcnc!ncsu!uvacs!edison!steinmetz!davidsen From: davidsen@steinmetz.UUCP (Davidsen) Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <779@steinmetz.UUCP> Date: Mon, 9-Jun-86 14:41:31 EDT Article-I.D.: steinmet.779 Posted: Mon Jun 9 14:41:31 1986 Date-Received: Wed, 11-Jun-86 06:23:33 EDT References: <1462@mmintl.UUCP> <5498@alice.uUCp> <1497@mmintl.UUCP> Reply-To: davidsen@kbsvax.UUCP (Davidsen) Organization: GE CRD, Schenectady, NY Lines: 145 I resisted commenting on the original or followup of this, but I can't resist on this round! In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <5498@alice.uUCp> ark@alice.UUCP writes: >>Frank Adams says: ... >>> 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. Use of the feature is not the same thing as "use left of assignment". The original request was poorly stated. As for "most but not all C operators are", please state which binary operator is not allowed to be used with assignment. >>> 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 > } *you* might do that, but most people would nest the "if (B)" after the "if (A)". if (A) { X if (B) { Y } } else { Z } ... discussion of #begdef deleted ... > >>> 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. 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. >>> 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. I once did this in a language called IMP (based on "B"), and it saved no end of pain. However, I can't see changing the language to provide a feature which can be provided by a preprocessor filter (I may even write one now that the idea strikes). >>> 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. You would break so many existing programs that you should wash your mind out with soap for even thinking this. X3J11 was very careful to make *additions* where appropriate, rather than break existing programs. ... discussion of multi-level break deleted ... >>> 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. It is obvious that you haven't read the standard. The new length is 31 characters for internal names. Using *all* characters would allow a valid program which had identifiers longer than the addressing space of some machines. X3J11 also limited the length of macros and number of levels of #include, so that "real C" could be implemented on reasonable sized machines. ... discussion of how wonderful standards are deleted ... > >Frank Adams ihnp4!philabs!pwa-b!mmintl!franka >Multimate International 52 Oakland Ave North E. Hartford, CT 06108 I believe the original posting also mentioned complex as a type, currently in C++, desirable in C. 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. If there is a followup C committee for "C90" or whatever, I hope to be able to participate again. Disclaimer: if I have misquoted anyone on the X3J11 committee or failed to quote them, the fault is mine. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen / sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"