Path: utzoo!mnetor!uunet!husc6!uwvax!umn-d-ub!umn-cs!meccts!viper!john
From: john@viper.Lynx.MN.Org (John Stanley)
Newsgroups: comp.lang.c
Subject: Re: ANSI C idea: structure literals (and short constants)
Message-ID: <744@viper.Lynx.MN.Org>
Date: 23 Mar 88 17:20:54 GMT
References: <12244@brl-adm.ARPA> <2768@mmintl.UUCP>
Reply-To: john@viper.Lynx.MN.Org (John Stanley)
Organization: DynaSoft Systems
Lines: 66

In article <2768@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
 >>They're not, but the point is that this is a totally new meaning for a
 >>cast.  Usually, a cast is a unary operator.  Here, it's part of the
 >>description, like a declaration.  ...  In your proposal, (struct a){...}
 >>and (struct b){...} imply different values for {...}. ...  Also, your
 >>(struct ..) cast will produce an lvalue, which is also a big inconsistency.
 >
 >This is the wrong the interpretation of this syntax.  If such a syntax is
 >adopted, the correct interpretation runs as follows:

  While I agree that the original poster had the wrong idea (it's
pretty obvious that a constant, struct or not, can't possibly be an
lvalue), I somewhat resent the attitude that your interpretation is 
"The one and only" correct one.  I happen to disagree with part of your
interpretation.  Does that mean I'm wrong, or just that there's still
discussion necessary?

 >	An expression of the form {...} is of an anonymous struct type,
 >	whose components are unnamed, and have the types of the
 >	expressions given.  Casting a struct to another struct results
 >	in an element by element cast of the components of the first
 >	struct to the components of the second.  Likewise for casting a
 >	struct to an array.

  I think you're on the right track, and I can see some definate
usefulness in the definition as you've defined it, but it looks like
we might run into some problems in implementing it.  What if the
struct(s) have a different number of elements?  What happens if you
cast a struct containing a long into a character array?  This is a
start, but it needs more work.

 >	Taking the address of a constant results in a literal copy of
 >	the constant being allocated, and the result is a constant
 >	pointer to that literal.

  I can't see any usefulness to this part of your proposal.  It
introduces the necessity for dynamic creation of data with the
mechinism compleatly hidden from the programmer.  If the programmer
wants a copy, let the programmer do it.  Let the programmer treat a
constant struct as a constant, not something that's going to move
every time he/she calls a function containing one.
  A constant struct should be allocated as part of the constant data
page same as any string.  Currently, there's no difference between:
   char aba[10] = "abcdefghi";
      and
   char aba[10] = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', '\0'};
and I can't see any reason we should change this aspect of the
language...
 
 >The main problem with this proposal is the parsing problem.  When do {}'s
 >enclose a struct literal, and when a compound statement?  The parser
 >must be able to tell when it sees the first {.

  The parser doesn't need to know anything.  It's not the parsers job
to know anything about compound statements or structs...  The compiler,
on the other hand, should be able to differentiate from context (same 
way it would when compiling a variable definition line like the char 
array one given above.

 >Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
 >Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john