typeof

Richard O'Keefe ok at edai.UUCP
Tue Jul 24 21:50:38 AEST 1984


     I know the C standards group are trying to minimise changes
to the language, but there is one change which shouldn't do much
harm and would help people writing macros.  Let

	typeof <thing>

(where <thing> is whatever sizeof <thing> would allow) be used
as a type specifier.  Why would this be useful?  So that people
could define macros like

#define swap(x,y) {typeof x  *ZQ1 = &(x), *ZQ2 = &(y), t;\
		   t = *ZQ1, *ZQ1 = *ZQ2, *ZQ2 = t;}
/*  If there is a better way of defining this to work when
    x and y may contain arbitrary side-effective expressions
    I'd like to know it.
*/
#define SetNull(x) x = (typeof x)(0)

     The definition should explicitly say that the <thing> is
NOT evaluated (otherwise "swap" won't work).

     Someone said that the standard allows white space before a
sharp.  I hope this was a misunderstanding, and that explicitly
allowing white space after a sharp was meant.  Till now people
have been able to use " #" for tools that manipulate C code,
secure in the knowledge that C can't use sharps anywhere, and
the preprocessor can only see them in the first column.  (E.g.
there is a tool that lets you write end-of-line comments like
Ratfor instead of ugly /**/ filth.)  This change would break
those tools.  I can't see what the change is FOR; if you're
worried about the indentation you can leave the sharp at the
left margin and indent the keyword.

     Re the use of
#define	QUOTE(X) X
#define CONCAT(x,y) QUOTE(x)y
it was my understanding that the preprocessor was entitled to
include the newline (or a corresponding space) that ended the
definition of QUOTE in its expansion, so might not CONCAT(a,b)
expand to "a b"? The ONLY satisfactory answer to this problem is
for some public-spirited hero to write a public domain C
preprocessor in (sub-)standard C and send it to net.sources.
I'd do it myself, but I haven't got the time right now.

     This business of 6 letter external names, I don't
understand it.  COBOL has had 30-character names for YEARS, and
several COBOL compilers have a form of separate compilation.  If
a linker or object module format can handle 30-character
monocase names with hyphens, it can handle 30-character monocase
names with underscores (mapped to hyphens).  I suppose we should
be grateful that no-one is worried about IBM 1130 compatibility
or we'd have 5 letter external names!



More information about the Comp.lang.c mailing list