extra comma

[aar...@gmail.com]

Hi all,

why does C language permits an extra comma in initializer list

ex:- int days[] = {
31,28.31,30,31,30,
31,31,30,31,30,31,
}
i have heard it is for the purpose of automatic code generation
is there any other purpose than this, if so why ...????

[Richard Heathfield]

aar...@gmail.com said:

> Hi all,
>
> why does C language permits an extra comma in initializer list
>
> ex:- int days[] = {
> 31,28.31,30,31,30,

Between 31 and 28 you meant ,, not ..

> 31,31,30,31,30,31,
> }
> i have heard it is for the purpose of automatic code generation

That's supposed to be the reasoning behind such lamenesses, yes. But
observe:

i = 0;
printf(" %d", day[i]);
while(i++ < 12)
{
printf(", %d%s", day[i], (i % 6) == 5 ? "\n" : "");
}

So, as you can see, it isn't actually difficult to generate the code
without the trailing comma.

> is there any other purpose than this, if so why ...????

No, it's just catering for the lazy.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[vipp...@gmail.com]

On Feb 16, 7:14 pm, Richard Heathfield <r...@see.sig.invalid> wrote:

> aark...@gmail.com said:
>
> > Hi all,
>
> > why does C language permits an extra comma in initializer list
>
> > ex:- int days[] = {
> > 31,28.31,30,31,30,
>
> Between 31 and 28 you meant ,, not ..

How do you know? 28.31 is a valid value for initializing in integer
context.

>
> > 31,31,30,31,30,31,
> > }
> > i have heard it is for the purpose of automatic code generation
>
> That's supposed to be the reasoning behind such lamenesses, yes. But
> observe:
>
> i = 0;
> printf(" %d", day[i]);
> while(i++ < 12)
> {
> printf(", %d%s", day[i], (i % 6) == 5 ? "\n" : "");
>
> }
>
> So, as you can see, it isn't actually difficult to generate the code
> without the trailing comma.

Modulus or even the conditional check could be expensive somewhere I
guess.
Notice it's not only allowed in an "initializer list" but anywhere
where {elements} is used. (I don't know the proper term for it)
For example, printf("%zu\n", sizeof (char[]){1,2,3,});

[Martin]

On Feb 16, 4:55 pm, aark...@gmail.com wrote:
> why does C language permits an extra comma in initializer list

> ...

>  i have heard it is for the purpose of automatic code generation
> is there any other purpose than this, if so why ...????

According to K&R2 (p196) it is "a nicety for neat formatting."

--
Martin

[Richard Heathfield]

vipp...@gmail.com said:

> On Feb 16, 7:14 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> aark...@gmail.com said:
>>
>> > Hi all,
>>
>> > why does C language permits an extra comma in initializer list
>>
>> > ex:- int days[] = {
>> > 31,28.31,30,31,30,
>>
>> Between 31 and 28 you meant ,, not ..
> How do you know?

Call me psychic if you like.

> 28.31 is a valid value for initializing in integer
> context.

Yes, but on this occasion it was not what was intended.

<snip>

>> So, as you can see, it isn't actually difficult to generate the code
>> without the trailing comma.
> Modulus or even the conditional check could be expensive somewhere I
> guess.

My % could have been avoided if necessary, but in any case it was to deal
with the newline, not the comma.

[Ben Pfaff]

Richard Heathfield <r...@see.sig.invalid> writes:

> aar...@gmail.com said:
>> why does C language permits an extra comma in initializer list

>> i have heard it is for the purpose of automatic code generation
>
> That's supposed to be the reasoning behind such lamenesses, yes. But
> observe:
>
> i = 0;
> printf(" %d", day[i]);
> while(i++ < 12)
> {
> printf(", %d%s", day[i], (i % 6) == 5 ? "\n" : "");
> }

Observe:

int array[] = {
#ifdef ELEMENT_ONE
1,
#endif
#ifdef ELEMENT_TWO
2,
#endif
#ifdef ELEMENT_THREE
3,
#endif
#ifdef ELEMENT_FOUR
4,
#endif
};

versus:

int array[] = {
#ifdef ELEMENT_ONE
1
# if (defined(ELEMENT_TWO) || defined(ELEMENT_THREE) \
|| defined(ELEMENT_FOUR))
,
# endif
#endif
#ifdef ELEMENT_TWO
2,
# if defined(ELEMENT_THREE) || defined(ELEMENT_FOUR)
,
# endif
#endif
#ifdef ELEMENT_THREE
3
# if defined(ELEMENT_FOUR)
,
# endif
#endif
#ifdef ELEMENT_FOUR
4,
#endif
};

I know which one I would prefer to maintain.
--
"The expression isn't unclear *at all* and only an expert could actually
have doubts about it"
--Dan Pop

[Richard Heathfield]

Ben Pfaff said:

> Richard Heathfield <r...@see.sig.invalid> writes:

<snip>

> I know which one I would prefer to maintain.

Surely the whole point of generating the code automatically is that you
don't have to maintain it?

[Ben Pfaff]

Richard Heathfield <r...@see.sig.invalid> writes:

> Ben Pfaff said:
>
>> Richard Heathfield <r...@see.sig.invalid> writes:
>
> <snip>
>
>> I know which one I would prefer to maintain.
>
> Surely the whole point of generating the code automatically is that you
> don't have to maintain it?

The code that you snipped was not an example of automatically
generated code.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[rzed]

Richard Heathfield <r...@see.sig.invalid> wrote in
news:f9CdnWNCHtOThCra...@bt.com:

> aar...@gmail.com said:
>
>> Hi all,
>>
>> why does C language permits an extra comma in initializer list
>>
>> ex:- int days[] = {
>> 31,28.31,30,31,30,
>
> Between 31 and 28 you meant ,, not ..
>
>> 31,31,30,31,30,31,
>> }
>> i have heard it is for the purpose of automatic code
>> generation
>
> That's supposed to be the reasoning behind such lamenesses, yes.
> But observe:
>
> i = 0;
> printf(" %d", day[i]);
> while(i++ < 12)
> {
> printf(", %d%s", day[i], (i % 6) == 5 ? "\n" : "");
> }
>
> So, as you can see, it isn't actually difficult to generate the
> code without the trailing comma.
>
>> is there any other purpose than this, if so why ...????
>
> No, it's just catering for the lazy.
>

And what's wrong with that? A compiler is just catering to those
too lazy to code machine language directly.

One benefit of allowing the extra comma (albeit for the lazy) is
that it allows you to manually reorder lists of items in an editor
without having to go back and add a comma here and take it away
there.

I don't see the harm in allowing the trailing comma, and there is
at least some productivity benefit.

--
rzed

[Richard Heathfield]

Ben Pfaff said:

> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> Ben Pfaff said:
>>
>>> Richard Heathfield <r...@see.sig.invalid> writes:
>>
>> <snip>
>>
>>> I know which one I would prefer to maintain.
>>
>> Surely the whole point of generating the code automatically is that you
>> don't have to maintain it?
>
> The code that you snipped was not an example of automatically
> generated code.

Oh. I see.

<bright smile, a la Dory from "Finding Nemo">

Well then - perhaps you ought to automate it! :-)

[Richard Heathfield]

rzed said:

> Richard Heathfield <r...@see.sig.invalid> wrote in
> news:f9CdnWNCHtOThCra...@bt.com:
>
>> aar...@gmail.com said:

<snip>

>>> is there any other purpose than this, if so why ...????
>>
>> No, it's just catering for the lazy.
>
> And what's wrong with that? A compiler is just catering to those
> too lazy to code machine language directly.

Right. And keyboards are lame, too - we should be using plugboards.

> One benefit of allowing the extra comma (albeit for the lazy) is
> that it allows you to manually reorder lists of items in an editor
> without having to go back and add a comma here and take it away
> there.

True enough. In fact, that's catering for the good kind of lazy (yes, there
are at least two kinds). Of course, manually reordering lists is easy
enough even if you don't like the trailing comma. Reorder, remove last
comma, recompile, and the editor will tell you where to insert the comma.
:-)

> I don't see the harm in allowing the trailing comma, and there is
> at least some productivity benefit.

I certainly wouldn't want to see the feature /removed/ from the language.
Had I been consulted as to its original addition, I'd probably have argued
against it, but hey - it's there, it works, it does no particular harm, so
no big deal. (Of course, removing it from the Standard would do no harm
either, since the standardisation process is effectively dead in the water
now.)

[Ben Pfaff]

Richard Heathfield <r...@see.sig.invalid> writes:

> Ben Pfaff said:
>
>> Richard Heathfield <r...@see.sig.invalid> writes:
>>
>>> Ben Pfaff said:
>>>
>>>> Richard Heathfield <r...@see.sig.invalid> writes:
>>>
>>> <snip>
>>>
>>>> I know which one I would prefer to maintain.
>>>
>>> Surely the whole point of generating the code automatically is that you
>>> don't have to maintain it?
>>
>> The code that you snipped was not an example of automatically
>> generated code.
>
> Oh. I see.
>
> <bright smile, a la Dory from "Finding Nemo">
>
> Well then - perhaps you ought to automate it! :-)

Fortunately, I have no need to do so, because trailing commas are
allowed in initializer lists (and elsewhere).
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Richard Heathfield]

Ben Pfaff said:

> Richard Heathfield <r...@see.sig.invalid> writes:
>
<snip>

>> Well then - perhaps you ought to automate it! :-)

>
> Fortunately, I have no need to do so, because trailing commas are
> allowed in initializer lists (and elsewhere).

Um, I only suggested that because it really, really, really looked like a
good candidate for automation. Very repetitive, easy for people to screw
up during maintenance... it's a natural.

[Ben Pfaff]

Richard Heathfield <r...@see.sig.invalid> writes:

> Ben Pfaff said:
>
>> Richard Heathfield <r...@see.sig.invalid> writes:
>>> Well then - perhaps you ought to automate it! :-)
>>
>> Fortunately, I have no need to do so, because trailing commas are
>> allowed in initializer lists (and elsewhere).
>
> Um, I only suggested that because it really, really, really looked like a
> good candidate for automation. Very repetitive, easy for people to screw
> up during maintenance... it's a natural.

Hmm. I appreciate the thought, but I haven't noticed that
similar lists have been a problem in practice in the projects
that I'm involved in, as long as they don't grow absurdly large.
If they do grow too large, then automation is certainly a
reasonable option.

[Keith Thompson]

Richard Heathfield <r...@see.sig.invalid> writes:
> Ben Pfaff said:
>> Richard Heathfield <r...@see.sig.invalid> writes:
>
> <snip>
>
>> I know which one I would prefer to maintain.
>
> Surely the whole point of generating the code automatically is that you
> don't have to maintain it?

I think Ben's point (not that I'd presume to speak for him) is that
the trailing-comma rule can make it easier to maintain the code that
generates the code.

If you want to generate an initializer list and you already have all
the information in an array, then the trailing-comma rule doesn't help
much; it's easy enough to know when you're about to write the last
element and drop the comma. It's *slightly* more convenient to be
able to generate a comma after every item, but not enough to be worth
marring the language.

But if you don't know whether the current item is the last one until
after you've written it (say, you're reading input from a file), then
being able to write the trailing comma after every item can be more
significantly convenient.

It's still not impossible to avoid the trailing comma (if nothing
else, you can build an array or list internally and write the whole
initializer only when it's complete), and I still have mixed feelings
about whether the rule is worthwhile, but it's not completely useless.

An interesting (I think) point is that I've never heard anyone
complain that semicolons are used as terminators rather than as
separators, as they are in Pascal. The fact that we can (and must)
write:
{
statement1;
statement2;
}
rather than
{
statement1;
statement2
}
makes programs easier to maintain when we want to add a third
statement. But the idea that a comma should be a terminator rather
than a separator seems somehow unnatural -- even though they're both
separators in written English.

To summarize:

{ statement1; statement2; } /* good */
{ statement1; statement2 } /* bad */
{ initializer1, initializer2, } /* bad */
{ initializer1, initializer2 } /* good */

--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Thad Smith]

Ben meant to omit the comma following "4", of course. Perhaps the mistake
helps illustrate his point.

Richard Heathfield wrote:

> Ben Pfaff said:
>> I know which one I would prefer to maintain.
>

> Surely the whole point of generating the code automatically is that you
> don't have to maintain it?

Ben's example was for code that is manually written and maintained, not
automatically generated. I think his point has merit.

--
Thad

[Malcolm McLean]

"Keith Thompson" <ks...@mib.org> wrote in message

> An interesting (I think) point is that I've never heard anyone
> complain that semicolons are used as terminators rather than as
> separators, as they are in Pascal. The fact that we can (and must)
> write:
> {
> statement1;
> statement2;
> }
> rather than
> {
> statement1;
> statement2
> }
> makes programs easier to maintain when we want to add a third
> statement. But the idea that a comma should be a terminator rather
> than a separator seems somehow unnatural -- even though they're both
> separators in written English.
>

Most people don't know the rules for semicolons in written English. The
semi-colon can be used to introduce a list, or to separate two parts of a
sentence which are themselves valid sentences (periods).

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ben Pfaff]

"Malcolm McLean" <regn...@btinternet.com> writes:

> Most people don't know the rules for semicolons in written
> English. The semi-colon can be used to introduce a list, or to
> separate two parts of a sentence which are themselves valid sentences
> (periods).

Ordinarily, a colon, not a semicolon, would be used in English to
introduce a list.
--
Ben Pfaff
http://benpfaff.org

[Malcolm McLean]

"Ben Pfaff" <b...@cs.stanford.edu> wrote in message
news:877ih4l...@blp.benpfaff.org...

I mean terminate a comma-separated list.

[Mark McIntyre]

Richard Heathfield wrote:

> good candidate for automation. Very repetitive, easy for people to screw
> up during maintenance...

Not in my experience, no. Perhaps you just worked with lower grade
maintenance droids?
gd&r.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[SM Ryan]

aar...@gmail.com wrote:
# Hi all,
#
# why does C language permits an extra comma in initializer list

Keypunching.

You don't want to modify an existing card deck just because you
insert a new card in the deck. It's the same reason for the semicolon
rules.

If you want to understand this better, next time to edit a source
file, restrict your actions to only
Deleting an entire line.
Inserting an entire line.
Moving existing lines.
Retyping an entire line.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
OOOOOOOOOO! NAVY SEALS!

[Ian Collins]

SM Ryan wrote:
> aar...@gmail.com wrote:
> # Hi all,
> #
> # why does C language permits an extra comma in initializer list
>
> Keypunching.
>
> You don't want to modify an existing card deck just because you
> insert a new card in the deck. It's the same reason for the semicolon
> rules.
>

I thought legalising the trailing comma was new in C99. Not many card
readers where in use in 1999.

--
Ian Collins.

[karthikbalaguru]

On Feb 16, 11:23 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> rzed said:
>
> > Richard Heathfield <r...@see.sig.invalid> wrote in
> >news:f9CdnWNCHtOThCra...@bt.com:
>

> >> aark...@gmail.com said:
>
> <snip>
>
> >>> is there any other purpose than this, if so why ...????
>
> >> No, it's just catering for the lazy.
>
> > And what's wrong with that? A compiler is just catering to those
> > too lazy to code machine language directly.
>
> Right. And keyboards are lame, too - we should be using plugboards.
>
> > One benefit of allowing the extra comma (albeit for the lazy) is
> > that it allows you to manually reorder lists of items in an editor
> > without having to go back and add a comma here and take it away
> > there.
>
> True enough. In fact, that's catering for the good kind of lazy (yes, there
> are at least two kinds). Of course, manually reordering lists is easy
> enough even if you don't like the trailing comma. Reorder, remove last
> comma, recompile, and the editor will tell you where to insert the comma.
> :-)
>
> > I don't see the harm in allowing the trailing comma, and there is
> > at least some productivity benefit.
>
> I certainly wouldn't want to see the feature /removed/ from the language.
> Had I been consulted as to its original addition, I'd probably have argued
> against it, but hey - it's there, it works, it does no particular harm, so
> no big deal. (Of course, removing it from the Standard would do no harm
> either, since the standardisation process is effectively dead in the water
> now.)
>

These extra commas are permitted but are not required.
A benefit is in manual re-oredering. :):)

Karthik Balaguru

[Jack Klein]

On Sun, 17 Feb 2008 14:18:51 +1300, Ian Collins <ian-...@hotmail.com>
wrote in comp.lang.c:

Legalizing the trailing comma in an enumeration declaration was new in
C99. The optional trailing comma was left out of the ANSI 89/ISO 90
grammar by mistake.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Army1987]

Richard Heathfield wrote:

> aar...@gmail.com said:
>
>> Hi all,
>>
>> why does C language permits an extra comma in initializer list
>>
>> ex:- int days[] = {
>> 31,28.31,30,31,30,
>
> Between 31 and 28 you meant ,, not ..
>
>> 31,31,30,31,30,31,
>> }
>> i have heard it is for the purpose of automatic code generation
>
> That's supposed to be the reasoning behind such lamenesses, yes. But
> observe:
>
> i = 0;
> printf(" %d", day[i]);
> while(i++ < 12)
> {
> printf(", %d%s", day[i], (i % 6) == 5 ? "\n" : "");
> }
>
> So, as you can see, it isn't actually difficult to generate the code
> without the trailing comma.

int foo[] = {
#ifdef FOO
42, 0,
#endif
37, EOF,
#ifdef BAR
'\n', EXIT_FAILURE,
#endif
#ifdef BAZ
SEEK_END, ERANGE,
#endif
}

--
Army1987 (Replace "NOSPAM" with "email")

[Harald van Dijk]

On Sun, 17 Feb 2008 11:15:44 +0000, Army1987 wrote:
> Richard Heathfield wrote:
>> So, as you can see, it isn't actually difficult to generate the code
>> without the trailing comma.
>
> int foo[] = {
> #ifdef FOO
> 42, 0,
> #endif
> 37, EOF,
> #ifdef BAR
> '\n', EXIT_FAILURE,
> #endif
> #ifdef BAZ
> SEEK_END, ERANGE,
> #endif
> }

int foo[] = {
#ifdef FOO
42, 0,
#endif
37, EOF

#ifdef BAR
,'\n', EXIT_FAILURE
#endif
#ifdef BAZ
,SEEK_END, ERANGE
#endif
}

It's not difficult when you have at least one fixed item in the list.

[William Pursell]

On Feb 16, 5:38 pm, Ben Pfaff <b...@cs.stanford.edu> wrote:

> Observe:
>
> int array[] = {
> #ifdef ELEMENT_ONE
> 1,
> #endif

<snip>

> };
>
> versus:
>
> int array[] = {
> #ifdef ELEMENT_ONE
> 1
> # if (defined(ELEMENT_TWO) || defined(ELEMENT_THREE) \
> || defined(ELEMENT_FOUR))
> ,
> # endif
> #endif

<snip>

> };
>
> I know which one I would prefer to maintain.

I can't think of too many cases where it is problematic to do:

int array[] = {
#ifdef ELEMENT_ONE
1,
#endif

SENTINEL
};

to force the existence of at least one fixed
element.

[Army1987]

Harald van Dijk wrote:

> int foo[] = {
> #ifdef FOO
> 42, 0,
> #endif
> 37, EOF
> #ifdef BAR
> ,'\n', EXIT_FAILURE
> #endif
> #ifdef BAZ
> ,SEEK_END, ERANGE
> #endif
> }
>
> It's not difficult when you have at least one fixed item in the list.

But it is so ugly! :-)

[aar...@gmail.com]

On Feb 16, 10:33 pm, Richard Heathfield <r...@see.sig.invalid> wrote:

> vipps...@gmail.com said:
>
> > On Feb 16, 7:14 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> aark...@gmail.com said:
>
> >> > Hi all,
>
> >> > why does C language permits an extra comma in initializer list
>
> >> > ex:- int days[] = {
> >> > 31,28.31,30,31,30,
>
> >> Between 31 and 28 you meant ,, not ..
> > How do you know?
>
> Call me psychic if you like.
>
> > 28.31 is a valid value for initializing in integer
> > context.
>
> Yes, but on this occasion it was not what was intended.

Yeah richard is correct he is indeed psychic to a certain extent
I did n't mean 28.31 , i meant 28,31