bjornc@kuling.UUCP (Bj|rn Carlsson) (03/01/88)
Why is an optional trailing comma inside the braces after an initializer-list allowed? Since it doesn't affect the meaning of the initializer we can't see any other reasons for including it except historical. Is it included in the Draft proposed ANSI C? We are currently writing a compiler for a subset of C and got a bit confused when finding this strange syntax. It is documented in both K&R and Harbison&Steele (2nd ed.).
flaps@dgp.toronto.edu (Alan J Rosenthal) (03/14/88)
In article <660@kuling.UUCP> bjornc@kuling.UUCP (Bj|rn Carlsson) writes: >Why is an optional trailing comma inside the braces after an >initializer-list allowed? Ah, this is a very useful thing. Suppose you have something like: struct thatthing stuff[] = { { "squid", 145, 5.2, "fish" }, { "parsley", 130, 2.5, "vegetable" }, { "flaps", 556, 2.1, "human" }, { "C", 11, 0.598, "programming language" }, }; It is _much_ easier to edit a list like this if every line has the same format, including the trailing comma. It is also somewhat easier to generate automatically. >Is it included in the Draft proposed ANSI C? Yes. -- If you had eternal life, would you be able to say all the integers?
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/14/88)
In article <660@kuling.UUCP> bjornc@kuling.UUCP (Bj|rn Carlsson) writes: >Why is an optional trailing comma inside the braces after an initializer-list >allowed? It makes automatically-generated tables and conditionally-compiled tables easier to deal with.
blarson@skat.usc.edu (Bob Larson) (03/14/88)
It is VERY useful. Try the following without it:
(Case D, E, and F may be added later.)
/* one or more of A, B and C are defined */
char *foo[] = { /* must be alphabetical */
#ifdef A
"a",
#endif
#ifdef B
"b",
#endif
#ifdef C
"c",
#endif
};
Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list: info-prime-request%fns1@ecla.usc.edu
oberon!fns1!info-prime-request
g-rh@cca.CCA.COM (Richard Harter) (03/14/88)
In article <660@kuling.UUCP> bjornc@kuling.UUCP (Bj|rn Carlsson) writes: >Why is an optional trailing comma inside the braces after an initializer-list >allowed? Since it doesn't affect the meaning of the initializer we can't >see any other reasons for including it except historical. Is it included >in the Draft proposed ANSI C? We are currently writing a compiler for a >subset of C and got a bit confused when finding this strange syntax. >It is documented in both K&R and Harbison&Steele (2nd ed.). This is one of those little things that makes life a little nicer for people who have to maintain code. Suppose you have a table of records, with one item per line, all nicely aligned in columns for readibility. Suppose you want to add a new record; you may enter a new record with out altering the line for the old record -- your code control rev history will be cleaner. Again, suppose that your table of initializers is machine generated; the generator code will be simpler if the last item is not a special case. Indeed, if you think about it, the specification is simpler if the comma is a terminator rather than a separator because all items in the specification list have the same format, instead of the last one having a special format. C's use of the semicolon is analogous; C uses a semicolon as a statement termninator rather than as a separator as in Algol and Pascal. In that case human factors studies have found that the C treatment is superior to the Algol treatment -- fewer semicolon errors are made when the C style is used than when the Algol style is used. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
daveb@laidbak.UUCP (Dave Burton) (03/15/88)
In article <660@kuling.UUCP> bjornc@kuling.UUCP (Bj|rn Carlsson) writes: >Why is an optional trailing comma inside the braces after an initializer-list >allowed? Since it doesn't affect the meaning of the initializer we can't >see any other reasons for including it except historical. Is it included >in the Draft proposed ANSI C? We are currently writing a compiler for a >subset of C and got a bit confused when finding this strange syntax. >It is documented in both K&R and Harbison&Steele (2nd ed.). I (ab)use this syntax all the time when writing programs with a large number of initializers. It is very useful when this list must undergo maintenance - additions, deletions, reorganization, etc. For example: static char *message[] = { "message", "another message", "yam", "...", "etc", }; If more messages need to be added, just tack 'em on. It also has the potential to make automatic program generators (a trivial amount) easier to implement. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include <disclaimer.h> Naperville, IL 60540
martin@kuling.UUCP (Erik Martin) (03/16/88)
In article <25526@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >[...] Again, suppose that your table of initializers is machine >generated; the generator code will be simpler if the last item is not a >special case. Indeed, if you think about it, the specification is simpler >if the comma is a terminator rather than a separator because all items in >the specification list have the same format, instead of the last one having >a special format. Then, why isn't an 'optional' comma allowed after the last constant in an enumeration list? I bumbed into this fact when I needed to generate both an initialized array and an enumeration declaration from a file of symbols, and found that I had to give special treatment to the last item in the enumeration. *Very* frustrating. -- ((Per-Erik Martin, Computing Science Dept., Uppsala University, ) (Box 520, S-751 20 Uppsala, Sweden ) (UUCP: martin@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!martin)))
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/20/88)
In article <680@kuling.UUCP> martin@kuling.UUCP (Per-Erik Martin) writes: >Then, why isn't an 'optional' comma allowed after the last constant in an >enumeration list? I don't recall this suggestion having been sent in, but it seems like a good one (certainly it wouldn't break existing correct code). Send it in; who knows, maybe it isn't too late. (Although it probably is.)