Using strings as immediate char

Cesar Quiroz quiroz at rochester.ARPA
Mon Aug 25 14:34:26 AEST 1986


Expires:

Sender:

Followup-To:


In a recent posting, referring to the "abc"[2] question:
>> sun!guy (Guy Harris) writes:
>> >(The real test, of course, is whether
>> >        cmdchr = menu_selection["rofq"];
>> >yields the  same result.    Any  compiler that doesn't  produce
>> >object code that yields the same result isn't a C compiler.)
>> 

To which karl at haddock replied asking why should it be so, and
suggested making it illegal, among other reasons because, presumably 
>> ...  It makes it easier to define
>> arrays as a real datatype in future implementations  if "x[y]" is
>> redefined slightly.

    Please notice that  "future implementations"   always have    to
decide   whether they want  to   be reasonably   compatible with the
language as it is.  The identity x[y] = *(x+y) is  so substantial to
C as it  is now, that an  implementation that  invalidated it  would
have trouble with *lots* of  reasonable current code.   For the sake
of argument, we can imagine calling our 'foo  x[];' things something
like vectors (as  C++ does) and then  inventing real  arrays (as you
want them). Then if the real arrays don't  obey the identity  above,
we better introduce new syntax, so most old programs are still valid
and *have the same meaning*, while some legal new programs (the ones
that depend on the extension) are distinguishably illegal in the Old
Standard.  I don't think it pays to patch C even more,  but at least
let's try for extensions that don't cause trouble.


Anybody for 'char txt]100[;' as the new syntax? :-)  That's more or
less what I had in mind.  No way to confuse them.  (Or there is?)
-- 
Cesar Augusto  Quiroz Gonzalez
Department of Computer Science     {allegra|seismo}!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz at ROCHESTER



More information about the Comp.lang.c mailing list