Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!bu.edu!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: Typeof operator in C (Re: An Interesting View of "Strong" Vs. "Weak" Typing)
Message-ID: <5293@buengc.BU.EDU>
Date: 15 Jan 90 20:46:34 GMT
References: <16678@megaron.cs.arizona.edu> <7106@tank.uchicago.edu> <-K016ODxds13@ficc.uu.net> <5263@buengc.BU.EDU> <-121H63ggpc2@ficc.uu.net>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.lang.c
Organization: Boston Univ. Col. of Eng.
Lines: 80

In article <-121H63ggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>[ Note, I frequently leave off attributions where they're not needed,
>  on the theory that you're less likely to flame a discussion if you
>  don't know the principals. Is this to be a discussion of ideas or
>  of personalities? ]

INAPPROPRIATE FLAME ON!
Perhaps then you should instead leave off your .sig, since you
are about the only person on the whole of the net whom I'm likely
to flame on sight.

Credit those who wrote their words, especially when you agree
with them, and stop being so damn supercilious about the
purpose of the net.
INAPPROPRIATE FLAME OFF...

>I said... what would typeof() return for some complex structure. This
>being the typeof that returns a first-class object, not the typeof from
>GCC 
>
>> `struct _T_aaa' or something similar.
>
>You mean it would return a string? That's an interesting idea. I would have
>expected it to return a small integer of some sort. You know: _T_INT,
>_T_CHAR, _T_DOUBLE.

Sorry, let me clarify:


You had asked what the meaning of the typeof expression would be
if it were applied to this rather complicated struct you had
devised; my response was that there really was nothing to worry
about, since a struct can be recognized from its struct-identifier
(the optionial name that comes right after the word 'struct'
and right before the optional left-brace in the declaration)
and hence the compiler would only have to take the typeof
expression, evaluate it, and then replace the expression with
its value, which would be the type-identifier.  So, in the
case where you don't think up the identifier yourself, the
compiler would make up a unique one and use it.

typeof should return a type identifier, rather than a data value.

It's obviously useful in situations where you need to do a cast
or a declaration but don't know the type of the object you're
casting or creating.  Specifically, it fits perfectly in that
swap-macro you devised:

#define swap(a,b) {typeof a tmp; tmp = a; a = b; b = tmp}

where the expansion of

	int x,y;
	...
	swap(x,y);

gives

	{int tmp; tmp = x ...

where it wouldn't work if the typeof operator returned anything
that was data, even integer constants or strings.

Returning to the struct example, I was using `_T_aaa' as the
sort of nebulous name a compiler might choose as the identifier
of an otherwise un-identifier'ed struct, and then defining

	struct {
		...
	} x;

would mean that `typeof x' would return this thing from the
symbol table that was the type-identifier for the variable x,
which might come out in a debugger something like

	struct _T_aaa

				--Blair
				  "As long as we're making up operators,
				   if ( dollarsin pocket != 0 )..."