chips@usfvax2.UUCP (Chip Salzenberg) (09/26/87)
About a year ago, I took an advanced C course conducted by Thom Plum. While
I had his ear, I suggested that X3J11 include structure constants in the
draft standard:
typedef struct { double r, i; } COMPLEX;
extern COMPLEX get_complex(), add_complex();
main()
{
COMPLEX a, b;
a = get_complex_from_somewhere();
/* Note the second parameter to this function call: */
b = add_complex(a, (COMPLEX){1.0, 1.0} );
}
Any thoughts from netlanders?
(Note that no new error messages are necessary, since most of the same work is
done in inititialization of auto aggregates, which is already in the draft.)
Anyone moved? Feel free to lobby X3J11... :-)
P.S. Don't bother posting "C++ can do that" articles;
this isn't comp.lang.c++.
--
Chip Salzenberg "chip%ateng@UU.NET" or "uunet!ateng!chip"
A.T. Engineering, Tampa CIS: 73717,366 Last Chance: "chips@usfvax2.UUCP"
"Use the Source, Luke!" My opinions do not necessarily agree with anything.henry@utzoo.UUCP (Henry Spencer) (09/29/87)
> b = add_complex(a, (COMPLEX){1.0, 1.0} );
What is the type of the second argument if you omit the cast? If the cast
is mandatory, then all of a sudden it isn't a cast any more, it's a new
kind of animal that happens to resemble a cast. (Speaking as an implementor,
if it's going to make casts any more messy to parse, I don't want to hear
about it!)
I suspect the answer from X3J11 (which has surely seen proposals along these
lines several times in the last couple of years) would be the standard one:
"no experience with this feature in real implementations; existing features
can be used to similar effect; no convincing demonstration of need".
Personally, I think it would be a useful thing, if you revised the syntax a
bit so the first part didn't look like a cast, but I am against adding it
to X3J11 in the absence of dire need.
--
"There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology
than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henrychip@ateng.UUCP (10/02/87)
In article <8677@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> b = add_complex(a, (COMPLEX){1.0, 1.0} ); > >What is the type of the second argument if you omit the cast? If the cast >is mandatory, then all of a sudden it isn't a cast any more, it's a new >kind of animal that happens to resemble a cast. (Speaking as an implementor, >if it's going to make casts any more messy to parse, I don't want to hear >about it!) Good point. The first thing that comes to mind is this: b = add_complex(a, COMPLEX {1.0, 1.0}); which in fact could be generalized to allow b = add_array(a, int[] {1, 2, 3, 4, 5}) which could still share compiler code with initialization of auto aggregates, and which would finally fix the inconsistency of allowing only character arrays to be anonymous. ........... [If arrays as well as structures were allowed, then for sanity, I would disallow defaulting to type "int"; that is, foo(int *[] { &static1, &static2 }); would be legal, whereas foo(*[] { &static1, &static2 }); would be illegal. An initial "*" should simply mean "indirection through".] ............ Of course, this new syntax causes statements like print_complex(COMPLEX {1.0, 1.0}); to look to the compiler very much like a function prototype; by the time the '{' is encountered, a lot of ass_u_me'ing might have to be undone. Fortunately, the latest draft says that function declarations inside block scope are undefined, or so I've heard. If this is true, then there's no conflict -- outside block scope, assume prototype or function definition; inside block scope, assume function call. >Personally, I think it would be a useful thing, if you revised the syntax a >bit so the first part didn't look like a cast, but I am against adding it >to X3J11 in the absence of dire need. But I have a dire need to get something into the draft! :-) >"There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology >than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry -- Chip Salzenberg "{uunet,usfvax2}!ateng!chip" or "chip%ateng@uu.net" A.T. Engineering (If my employer agrees with my opinions, it's news to me.) "The word is `no.' I am therefore going anyway." -- Adm. James T. Kirk
peter@sugar.UUCP (10/03/87)
In article <8677@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > b = add_complex(a, (COMPLEX){1.0, 1.0} ); > > What is the type of the second argument if you omit the cast? Pointer to array of two floats. Just use the arithmetic combination rules as if "," was an operator. Since you're now passing an array to a function he whole thing would be converted to a pointer. In this case it might be more appropriate to make them doubles... so you cast (I didn't see the original message, but I'm assuming you're using: typedef struct { double real, imag; } COMPLEX; or something morally equivalent). I implemented this in small-C for the 8080. Was a snap. I also implemented a bunch of other BCPLoid stuff. For example, you could do: A = { int i; for(i = 0; i < ac; i++) if(av[i]=="all") break; return i; }; Well, the rest will have to wait. My baby has just done something unspeakable and I have to go clean it up. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
xsimon@its63b.ed.ac.uk (Simon Brown) (10/03/87)
In article <843@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes: >I suggested that X3J11 include structure constants in the draft standard: > > typedef struct { double r, i; } COMPLEX; > extern COMPLEX get_complex(), add_complex(); > main() > { > COMPLEX a, b; > a = get_complex_from_somewhere(); > b = add_complex(a, (COMPLEX){1.0, 1.0} ); > } Why leave it just at structure constants? Expanding it to arrays would be *much* more useful. For example, (int []){ 1, 4, 6, 78, -67 } ((FILE *)[]){ stdin, stdout } ... would all be sensible constant expressions. And of course, the character-string notation "string of chars" would just be shorthand for (char []) { 's','t','r','i','n','g',' ','o','f',' ','c','h','a','r','s','\0' } You can't beat good honest anonymous data! %{ Simon. %} -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!{lfcs,its63b}!simon | Department of Computer Science | JANET: simon@uk.ac.ed.{lfcs,its63b} | University of Edinburgh, | ARPA: simon%lfcs.ed.ac.uk@cs.ucl.ac.uk | Scotland, UK. | or simon%its63b.ed.ac.uk@cs.ucl.ac.uk ---------------------------------- or simon%cstvax.ed.ac.uk@cs.ucl.ac.uk "Life's like that, you know"
wesommer@athena.mit.edu (William E. Sommerfeld) (10/05/87)
In article <667@its63b.ed.ac.uk> simon@its63b.ed.ac.uk (Simon Brown) writes: >In article <843@usfvax2.UUCP> chips@usfvax2.UUCP (Chip Salzenberg) writes: >>I suggested that X3J11 include structure constants in the draft standard: >Why leave it just at structure constants? Expanding it to arrays would be >*much* more useful. > >You can't beat good honest anonymous data! Why limit anonymity to data? If you're going to do that, why not also borrow a trick from Lisp, and include anonymous functions.. qsort(array_int, sizeof(array_int)/sizeof(int), sizeof(int), (int (*)(int *a, int *b)) { return *a-*b; }); - Bill
peter@sugar.UUCP (Peter da Silva) (10/12/87)
In article <1554@bloom-beacon.MIT.EDU>, wesommer@athena.mit.edu (William E. Sommerfeld) writes: > Why limit anonymity to data? If you're going to do that, why not also > borrow a trick from Lisp, and include anonymous functions.. > > qsort(array_int, sizeof(array_int)/sizeof(int), sizeof(int), > (int (*)(int *a, int *b)) { return *a-*b; }); Beautiful. Truly beautiful. I love it. The one feature of BCPL I didn't attempt implementing in Small-C. Doable, but a little tricky. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.