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