[comp.lang.c] { initializer-list , }

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.)