Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: ANSI C idea: structure literals
Message-ID: <2804@haddock.ISC.COM>
Date: 1 Mar 88 19:51:52 GMT
References: <56@vsi.UUCP> <1988Feb28.130526.4147@jarvis.csri.toronto.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 35
Keywords: ANSI, structure literals

In article <1988Feb28.130526.4147@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>In article <56@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>>        struct foo      *table[] = {
>>                & { "Bill",  25 },
>>                & { "Jim",   10 },
>>                & { "Bob",   40 },
>>        };
>
>This is good.  It is an analogue of what happens with strings.  It would be
>good to extend this to arrays and other things.  For example, why not be able
>to write "&3" to get a pointer to int which points to a 3?

(I'll use backquotes `` in running text to avoid colliding with C notation.)

I like the concept of unnamed remote objects, but I'm uneasy about allowing
`&` to apply to a non-lvalue.  I would prefer a more explicit syntax: let's
postulate a keyword `remote` that looks like a function call with two
arguments, the first of which is a type name, and the second an initializer;
the result is an unnamed lvalue of the specified type and value.  Thus,
instead of `&3` we write `&remote(int, 3)`.  The struct example would use
`&remote(struct foo, {"Bill", 25})`.  The existing notation for string
literals can now be described in terms of remotes: `"foo"` is synonymous with
`&remote(char[4], {'f', 'o', 'o', '\0'})`.  (All remotes, like strings in ANSI
C, should be non-writable and poolable at the implementor's discretion.)

This syntax is less kludgy than the other proposals I've seen, and by making
the type explicit we avoid the ambiguities.  Unfortunately it's a bit verbose.
It could be changed from an alphabetic operator to punctuation, but I suspect
the need is sufficiently rare that the longer name is acceptable.

>Of course, [`3` and `(short)3` are] already different when sizeof is used ...

Only on a broken compiler.  In C, `sizeof((short)3)` returns sizeof(int).
(Because `(short)3` is not an lvalue.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint