blocks|key|2945525|text|我一直认为添加额外的元素会更容易：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2945526|int+a[]+=+{
++++++++++++5,
++++++++++++6,
++++++++++};|code-block|syntax|javascript|2945527|简单地说就是：|2945528|int+a[]+=+{+
++++++++++++5,
++++++++++++6,
++++++++++++7,
++++++++++};|2945529|在以后的日子里。|2945530|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I've always assumed it makes it easier to append extra elements:

<pre><code>int a[] = {
 5,
 6,
 };
</code></pre>

simply becomes:

<pre><code>int a[] = { 
 5,
 6,
 7,
 };
</code></pre>

at a later date.

blocks|key|3159465|text|它使得生成源代码和编写代码变得更容易，这些代码在以后可以很容易地扩展。考虑向添加一个额外的条目需要什么：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3159466|int+a[]+=+{
+++1,
+++2,
+++3
};|code-block|syntax|javascript|3159467|..。您必须在现有行中添加逗号，然后添加一个新行。相比之下，三个字符后面已经有一个逗号，您只需添加一行即可。同样地，如果你想删除一行，你可以不用担心它是否是最后一行，你也可以重新排序行，而不需要使用逗号。基本上，这意味着你对待线条的方式是一致的。|3159468|现在考虑一下如何生成代码。类似于(伪代码)：|3159469|output("int+a[]+=+{");
for+(int+i+=+0;+i+<+items.length;+i%2B%2B)+{
++++output("%25s,+",+items[i]);
}
output("};");|3159470|不需要担心你正在写出的当前项目是第一个还是最后一个。简单多了。|3159471|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|U|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

It makes it easier to generate source code, and also to write code which can be easily extended at a later date. Consider what's required to add an extra entry to:

<pre><code>int a[] = {
 1,
 2,
 3
};
</code></pre>

... you have to add the comma to the existing line and add a new line. Compare that with the case where the three already has a comma after it, where you just have to add a line. Likewise if you want to remove a line you can do so without worrying about whether it's the last line or not, and you can reorder lines without fiddling about with commas. Basically it means there's a uniformity in how you treat the lines.

Now think about generating code. Something like (pseudo-code):

<pre><code>output("int a[] = {");
for (int i = 0; i &lt; items.length; i++) {
 output("%s, ", items[i]);
}
output("};");
</code></pre>

No need to worry about whether the current item you're writing out is the first or the last. Much simpler.

blocks|key|3159482|text|如果你这样做，它会很有用：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3159483|int+a[]+=+{
++1,
++2,
++3,+//You+can+delete+this+line+and+it's+still+valid
};|code-block|syntax|javascript|3159484|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

It's useful if you do something like this:

<pre><code>int a[] = {
 1,
 2,
 3, //You can delete this line and it's still valid
};
</code></pre>

blocks|key|3159488|text|原因很简单:易于添加/删除行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3159489|想象一下下面的代码：|3159490|int+a[]+=+{
+++1,
+++2,
+++//3,+//+-+not+needed+any+more
};|code-block|syntax|javascript|3159491|现在，您可以轻松地向列表添加/删除项目，而不必有时添加/删除尾随逗号。|3159492|与其他答案相比，我真的不认为生成列表容易是一个合理的原因:毕竟，对于代码来说，将最后一行(或第一行)作为特殊情况是微不足道的。代码生成器只需编写一次，就可以多次使用。|3159493|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

The reason is trivial: ease of adding/removing lines.

Imagine the following code:

<pre><code>int a[] = {
 1,
 2,
 //3, // - not needed any more
};
</code></pre>

Now, you can easily add/remove items to the list without having to add/remove the trailing comma sometimes.

In contrast to other answers, I don't really think that ease of generating the list is a valid reason: after all, it's trivial for the code to special-case the last (or first) line. Code-generators are written once and used many times.

blocks|key|3159551|text|它允许每一行都遵循相同的形式。首先，这使得添加新行变得更容易，并且有一个版本控制系统跟踪有意义的更改，它还允许您更容易地分析代码。我想不出什么技术原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3159552|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It allows every line to follow the same form. Firstly this makes it easier to add new rows and have a version control system track the change meaningfully and it also allows you to analyze the code more easily. I can't think of a technical reason.

blocks|key|3159578|text|开发人员的易用性，我认为。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3159579|int+a[]+=+{
++++++++++++1,
++++++++++++2,
++++++++++++2,
++++++++++++2,
++++++++++++2,
++++++++++++2,+/*line+I+could+comment+out+easily+without+having+to+remove+the+previous+comma*/
++++++++++}|code-block|syntax|javascript|3159580|此外，无论出于什么原因，如果您有一个工具可以为您生成代码，那么该工具不必关心它是否是初始化中的最后一项。|3159581|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Ease of use for the developer, I would think.

<pre><code>int a[] = {
 1,
 2,
 2,
 2,
 2,
 2, /*line I could comment out easily without having to remove the previous comma*/
 }
</code></pre>

Additionally, if for whatever reason you had a tool that generated code for you; the tool doesn't have to care about whether it's the last item in the initialize or not.

blocks|key|260028|text|据我所知，允许这样做的原因之一是自动生成代码应该很简单；您不需要对最后一个元素进行任何特殊处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|260029|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

One of the reasons this is allowed as far as I know is that it should be simple to automatically generate code; you don't need any special handling for the last element.

blocks|key|2945702|text|它使输出数组或枚举的代码生成器变得更容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2945703|想象一下：|2945704|std::cout+<<+"enum+Items+{\n";
for(Items::iterator+i(items.begin()),+j(items.end);+i+!=+j;+%2B%2Bi)
++++std::cout+<<+*i+<<+",\n";
std::cout+<<+"};\n";|code-block|syntax|javascript|2945705|也就是说，不需要对第一项或最后一项进行特殊处理，以避免吐出尾随的逗号。|2945706|例如，如果代码生成器是用Python语言编写的，那么通过使用str.join()函数可以很容易地避免输出尾随逗号：|offset|length|style|CODE|2945707|print("enum+Items+{")
print(",\n".join(items))
print("}")|2945708|entityMap^0|0|0|0|0|U|A|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@$M|Z|N|10|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|F|7|11|8|@]|9|@]|A|$G|H]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

It makes code generators that spit out arrays or enumerations easier.

Imagine:

<pre><code>std::cout &lt;&lt; "enum Items {\n";
for(Items::iterator i(items.begin()), j(items.end); i != j; ++i)
 std::cout &lt;&lt; *i &lt;&lt; ",\n";
std::cout &lt;&lt; "};\n";
</code></pre>

I.e., no need to do special handling of the first or last item to avoid spitting the trailing comma.

If the code generator is written in Python, for example, it is easy to avoid spitting the trailing comma by using <code>str.join()</code> function:

<pre><code>print("enum Items {")
print(",\n".join(items))
print("}")
</code></pre>

blocks|key|2945747|text|我认为，出于向后兼容性的原因，允许使用尾随逗号。有很多现有的代码，主要是自动生成的，放在后面的逗号。这使得在结尾没有特殊条件的情况下编写循环变得更容易。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2945748|for_each(my_inits.begin(),+my_inits.end(),
[](const+std::string&+value)+{+std::cout+<<+value+<<+",\n";+});|code-block|syntax|javascript|2945749|这对程序员来说并没有什么好处。|2945750|附注:虽然以这种方式自动生成代码更容易，但实际上我总是注意不要放在后面的逗号，这是最小的努力，可读性提高了，这是更重要的。你只写一次代码，你就会读很多次。|2945751|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Trailing comma I believe is allowed for backward compatibility reasons. There is a lot of existing code, primarily auto-generated, which puts a trailing comma. It makes it easier to write a loop without special condition at the end.
e.g.

<pre><code>for_each(my_inits.begin(), my_inits.end(),
[](const std::string&amp; value) { std::cout &lt;&lt; value &lt;&lt; ",\n"; });
</code></pre>

There isn't really any advantage for the programmer.

P.S. Though it is easier to autogenerate the code this way, I actually always took care not to put the trailing comma, the efforts are minimal, readability is improved, and that's more important. You write code once, you read it many times.

blocks|key|256063|text|在实践中，唯一不被允许的语言是Javascript，它导致了无数的问题。例如，如果您从数组的中间复制并粘贴一行，然后将其粘贴到末尾，并且忘记删除逗号，那么您的站点对于IE访问者来说将完全崩溃。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|256064|*理论上是允许的，但Internet+Explorer不遵循标准，并将其视为错误|256065|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The only language where it's - in practice* - not allowed is Javascript, and it causes an innumerable amount of problems. For example if you copy &amp; paste a line from the middle of the array, paste it at the end, and forgot to remove the comma then your site will be totally broken for your IE visitors.

*In theory it is allowed but Internet Explorer doesn't follow the standard and treats it as an error

blocks|key|3159768|text|对于机器来说，它更容易，即解析和生成代码。这对人类来说也更容易，即修改、注释和通过一致性实现视觉优雅。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3159769|假设C，你会写下下面的代码吗？|3159770|#include+<stdio.h>
#include+<stdlib.h>

int+main(void)
{
++++puts("Line+1");
++++puts("Line+2");
++++puts("Line+3");

++++return+EXIT_SUCCESS
}|code-block|syntax|javascript|3159771|不是的。不仅因为最后的语句是错误的，还因为它是不一致的。那么为什么要对集合做同样的事情呢？即使在允许省略最后一个分号和逗号的语言中，社区通常也不喜欢这样做。例如，Perl社区似乎不喜欢省略分号，除了一行代码。他们也将这一点应用于逗号。|3159772|不要在多行集合中省略逗号，这与在多行代码块中不省略分号的原因相同。我的意思是，即使语言允许，你也不会这么做，对吧？对吗？|3159773|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

It's easier for machines, i.e. parsing and generation of code.
It's also easier for humans, i.e. modification, commenting-out, and visual-elegance via consistency.

Assuming C, would you write the following?

<pre><code>#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;

int main(void)
{
 puts("Line 1");
 puts("Line 2");
 puts("Line 3");

 return EXIT_SUCCESS
}
</code></pre>

No. Not only because the final statement is an error, but also because it's inconsistent. So why do the same to collections? Even in languages that allow you to omit last semicolons and commas, the community usually doesn't like it. The Perl community, for example, doesn't seem to like omitting semicolons, bar one-liners. They apply that to commas too.

Don't omit commas in multiline collections for the same reason you don't ommit semicolons for multiline blocks of code. I mean, you wouldn't do it even if the language allowed it, right? Right?

blocks|key|258244|text|每个人所说的添加/删除/生成行的简单性都是正确的，但这种语法真正闪耀的地方是在将源文件合并在一起时。假设你有这样的数组：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|258245|int+ints[]+=+{
++++3,
++++9
};|code-block|syntax|javascript|258246|假设您已经将这段代码签入到存储库中。|258247|然后你的伙伴编辑它，添加到结尾：|258248|int+ints[]+=+{
++++3,
++++9,
++++12
};|258249|你同时编辑它，添加到开头：|258250|int+ints[]+=+{
++++1,
++++3,
++++9
};|258251|从语义上讲，这些类型的操作(添加到开头，添加到结尾)应该是完全合并安全的，并且您的版本控制软件(希望是git)应该能够自动合并。遗憾的是，情况并非如此，因为您的版本在9之后没有逗号，而您的伙伴的版本在9之后没有逗号。然而，如果原始版本有尾随的9，它们就会自动删除。|258252|因此，我的经验法则是:如果列表跨多行，请使用尾随逗号，如果列表在一行上，则不要使用逗号。|258253|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|10|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|12|8|@]|9|@]|A|$E|F]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Everything everyone is saying about the ease of adding/removing/generating lines is correct, but the real place this syntax shines is when merging source files together. Imagine you've got this array:

<pre><code>int ints[] = {
 3,
 9
};
</code></pre>

And assume you've checked this code into a repository.

Then your buddy edits it, adding to the end:

<pre><code>int ints[] = {
 3,
 9,
 12
};
</code></pre>

And you simultaneously edit it, adding to the beginning:

<pre><code>int ints[] = {
 1,
 3,
 9
};
</code></pre>

Semantically these sorts of operations (adding to the beginning, adding to the end) should be entirely merge safe and your versioning software (hopefully git) should be able to automerge. Sadly, this isn't the case because your version has no comma after the 9 and your buddy's does. Whereas, if the original version had the trailing 9, they would have automerged.

So, my rule of thumb is: use the trailing comma if the list spans multiple lines, don't use it if the list is on a single line.

blocks|key|2945870|text|除了代码生成和编辑的简单性之外，如果您想实现一个解析器，这种类型的语法更简单、更容易实现。C#在几个地方遵循这一规则，即有一个逗号分隔的项目列表，就像enum定义中的项目一样。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2945871|entityMap^0|23|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

In addition to code generation and editing ease, if you want to implement a parser, this type of grammar is simpler and easier to implement. C# follows this rule in several places that there's a list of comma-separated items, like items in an <code>enum</code> definition.

blocks|key|261402|text|如果您使用没有指定长度的数组，VC%2B%2B6.0会自动识别它的长度，所以如果您使用"int+a[]={1,2，}；“a的长度是3，但是最后一个数组没有初始化，您可以使用"cout<|type|unstyled|depth|inlineStyleRanges|entityRanges|data|261403|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you use an array without specified length,VC++6.0 can automaticly identify its length,so if you use "int a[]={1,2,};"the length of a is 3,but the last one hasn't been initialized,you can use "cout&lt;

blocks|key|2945921|text|这是为了防止因在长列表中移动元素而导致的错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2945922|例如，让我们假设我们有一个如下所示的代码。|2945923|#include+<iostream>
#include+<string>
#include+<cstddef>
#define+ARRAY_SIZE(array)+(sizeof(array)+/+sizeof+*(array))
int+main()+{
++++std::string+messages[]+=+{
++++++++"Stack+Overflow",
++++++++"Super+User",
++++++++"Server+Fault"
++++};
++++size_t+i;
++++for+(i+=+0;+i+<+ARRAY_SIZE(messages);+i%2B%2B)+{
++++++++std::cout+<<+messages[i]+<<+std::endl;
++++}
}|code-block|syntax|javascript|2945924|它很棒，因为它展示了Stack+Exchange站点的原始三部曲。|2945925|Stack+Overflow
Super+User
Server+Fault|2945926|但它有一个问题。你看，这个网站的页脚在超级用户之前显示了服务器故障。最好在别人注意到之前把它修好。|2945927|#include+<iostream>
#include+<string>
#include+<cstddef>
#define+ARRAY_SIZE(array)+(sizeof(array)+/+sizeof+*(array))
int+main()+{
++++std::string+messages[]+=+{
++++++++"Stack+Overflow",
++++++++"Server+Fault"
++++++++"Super+User",
++++};
++++size_t+i;
++++for+(i+=+0;+i+<+ARRAY_SIZE(messages);+i%2B%2B)+{
++++++++std::cout+<<+messages[i]+<<+std::endl;
++++}
}|2945928|毕竟，移动线条不会那么难，有可能吗？|2945929|Stack+Overflow
Server+FaultSuper+User|2945930|我知道，没有名为“服务器FaultSuper用户”的网站，但我们的编译器声称它存在。现在，问题是C有一个字符串连接特性，它允许您编写两个双引号的字符串并不使用任何东西来连接它们(类似的问题也可能发生在整数上，因为-符号有多种含义)。|offset|length|style|CODE|2945931|现在，如果原始数组的末尾有一个无用的逗号怎么办？好吧，这些行可能会被移动，但这样的bug不会发生。很容易遗漏像逗号这样的小东西。如果你记得在每个数组元素后面加一个逗号，这样的bug就不会发生。你是wouldn't+want+to+waste+four+hours+debugging+something,+until+you+would+find+the+comma+is+the+cause+of+your+problems。|2945932|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/fish-shell/fish-shell/commit/ed37427f9eb0a6dd436bfd087bcffdf869f96158^0|0|0|0|0|0|0|0|0|0|2Y|1|0|2Q|37|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1C|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1D|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1E|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1F|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1G|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|1H|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1I|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1J|8|@$W|1K|X|1L|Y|Z]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1M|8|@]|9|@$W|1N|X|1O|1|1P]]|A|$]]|$1|12|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]]]

This is allowed to protect from mistakes caused by moving elements around in a long list.

For example, let's assume we have a code looking like this.

<pre><code>#include &lt;iostream&gt;
#include &lt;string&gt;
#include &lt;cstddef&gt;
#define ARRAY_SIZE(array) (sizeof(array) / sizeof *(array))
int main() {
 std::string messages[] = {
 "Stack Overflow",
 "Super User",
 "Server Fault"
 };
 size_t i;
 for (i = 0; i &lt; ARRAY_SIZE(messages); i++) {
 std::cout &lt;&lt; messages[i] &lt;&lt; std::endl;
 }
}
</code></pre>

And it's great, as it shows the original trilogy of Stack Exchange sites.

<pre><code>Stack Overflow
Super User
Server Fault
</code></pre>

But there is one problem with it. You see, the footer on this website shows Server Fault before Super User. Better fix that before anyone notices.

<pre><code>#include &lt;iostream&gt;
#include &lt;string&gt;
#include &lt;cstddef&gt;
#define ARRAY_SIZE(array) (sizeof(array) / sizeof *(array))
int main() {
 std::string messages[] = {
 "Stack Overflow",
 "Server Fault"
 "Super User",
 };
 size_t i;
 for (i = 0; i &lt; ARRAY_SIZE(messages); i++) {
 std::cout &lt;&lt; messages[i] &lt;&lt; std::endl;
 }
}
</code></pre>

After all, moving lines around couldn't be that hard, could it be?

<pre><code>Stack Overflow
Server FaultSuper User
</code></pre>

I know, there is no website called "Server FaultSuper User", but our compiler claims it exists. Now, the issue is that C has a string concatenation feature, which allows you to write two double quoted strings and concatenate them using nothing (similar issue can also happen with integers, as <code>-</code> sign has multiple meanings).

Now what if the original array had an useless comma at end? Well, the lines would be moved around, but such bug wouldn't have happened. It's easy to miss something as small as a comma. If you remember to put a comma after every array element, such bug just cannot happen. You <a href="https://github.com/fish-shell/fish-shell/commit/ed37427f9eb0a6dd436bfd087bcffdf869f96158" rel="nofollow">wouldn't want to waste four hours debugging something, until you would find the comma is the cause of your problems</a>.

blocks|key|3159953|text|像许多事情一样，数组初始化器中的尾随逗号是C%2B%2B从C继承的内容之一(并且将永远支持)。在"Deep+C+secrets“一书中提到了一种与此处完全不同的观点。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3159954|下面是一个带有多个“逗号悖论”的例子：|3159955|char+*available_resources[]+=+{
"color+monitor"+++++++++++,
"big+disk"++++++++++++++++,
"Cray"++++++++++++++++++++++/*+whoa!+no+comma!+*/
"on-line+drawing+routines",
"mouse"+++++++++++++++++++,
"keyboard"++++++++++++++++,
"power+cables"++++++++++++,+/*+and+what's+this+extra+comma?+*/
};|code-block|syntax|javascript|3159956|我们读到：|3159957|3159958|+...that在最后一个初始化器后面的逗号不是一个拼写错误，而是是从原住民C遗留下来的语法中的一个小插曲。它的存在或不存在是允许的，但与无关。在ANSI基本原理中声称的理由是，它使C语言的自动生成更容易。如果允许在每个逗号分隔的列表中使用尾随逗号，例如在枚举声明中，或者在单个声明中使用多个变量声明符，则声明会更可信。他们不是。|blockquote|3159959|3159960|3159961|..。对我来说这更有意义|3159962|entityMap^0|17|Z|0|0|0|0|0|X|6|2V|E|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|14|8|@]|D|@]|E|$]]|$1|P|3|Q|5|R|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1C|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]]|X|$]]

Like many things, the trailing comma in an array initializer is one of the things C++ inherited from C (and will have to support for ever). A view totally different from those placed here is mentioned in the book "Deep C secrets". 

Therein after an example with more than one "comma paradoxes" : 

<pre><code>char *available_resources[] = {
"color monitor" ,
"big disk" ,
"Cray" /* whoa! no comma! */
"on-line drawing routines",
"mouse" ,
"keyboard" ,
"power cables" , /* and what's this extra comma? */
};
</code></pre>

we read : 

<blockquote>
 ...that trailing comma after the final initializer is not a typo, but a blip in the syntax carried over from aboriginal C. Its presence or absence is allowed but has no significance. The justification claimed in the ANSI C rationale is that it makes automated generation of C easier. The claim would be more credible if trailing commas were permitted in every comma-sepa-rated list, such as in enum declarations, or multiple variable declarators in a single declaration. They are not.
</blockquote>

... to me this makes more sense

blocks|key|261459|text|令我惊讶的是，这么多年来一直没有人引用Annotated+C%2B%2B+Reference+Manual(ARM)，它强调了我的以下关于dcl.init的内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|261460|261461|显然有太多的初始化符号，但每种符号似乎都很好地服务于一种特定的使用风格。+={initializer_list，opt}+表示法继承自C，很好地用于数据结构和数组的初始化。..。|blockquote|style|BOLD|261462|261463|261464|尽管从编写ARM开始，语法就一直在发展，但它的起源仍然存在。|261465|我们可以去C99+rationale看看为什么这在C中是允许的，它说：|261466|261467|+K&R允许在初始化器列表末尾的初始化器中使用逗号。该标准保留了此语法，因为它提供了在初始化器列表中添加或删除成员的灵活性，并简化了此类列表的机器生成。|261468|261469|entityMap|0|LINK|mutability|MUTABLE|url|http://www.stroustrup.com/arm.html|1|http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf^0|J|U|0|0|0|11|N|1P|7|0|0|0|0|5|D|1|0|0|13|11|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|D|3|-4|5|6|7|17|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|18|8|@$A|19|B|1A|H|I]|$A|1B|B|1C|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1G|8|@]|9|@$A|1H|B|1I|1|1J]]|C|$]]|$1|P|3|-4|5|6|7|1K|8|@]|9|@]|C|$]]|$1|Q|3|R|5|G|7|1L|8|@$A|1M|B|1N|H|I]]|9|@]|C|$]]|$1|S|3|-4|5|6|7|1O|8|@]|9|@]|C|$]]|$1|T|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]]|U|$V|$5|W|X|Y|C|$Z|10]]|11|$5|W|X|Y|C|$Z|12]]]]

I am surprised after all this time no one has quoted the <a href="http://www.stroustrup.com/arm.html" rel="noreferrer">Annotated C++ Reference Manual</a>(ARM), it says the following about [dcl.init] with emphasis mine:

<blockquote>
 There are clearly too many notations for initializations, but each seems to serve a particular style of use well. The ={initializer_list,opt} notation was inherited from C and serves well for the initialization of data structures and arrays. [...]
</blockquote>

although the grammar has evolved since ARM was written the origin remains.

and we can go to the <a href="http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf" rel="noreferrer">C99 rationale</a> to see why this was allowed in C and it says:

<blockquote>
 K&amp;R allows a trailing comma in an initializer at the end of an
 initializer-list. The Standard has retained this syntax, since it
 provides flexibility in adding or deleting members from an initializer
 list, and simplifies machine generation of such lists.
</blockquote>

blocks|key|3160015|text|我看到了一个在其他答案中没有提到的用例，我们最喜欢的宏：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3160016|int+a+[]+=+{
#ifdef+A
++++1,+//this+can+be+last+if+B+and+C+is+undefined
#endif
#ifdef+B
++++2,
#endif
#ifdef+C
++++3,
#endif
};|code-block|syntax|javascript|3160017|添加宏来处理最后一个,将是一件很痛苦的事情。有了这个语法上的小变化，这就很容易管理了。这比机器生成的代码更重要，因为通常用图灵完全语言比非常有限的预处理程序更容易做到这一点。|offset|length|style|CODE|3160018|entityMap^0|0|0|A|1|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I see one use case that was not mentioned in other answers,
our favorite Macros:

<pre><code>int a [] = {
#ifdef A
 1, //this can be last if B and C is undefined
#endif
#ifdef B
 2,
#endif
#ifdef C
 3,
#endif
};
</code></pre>

Adding macros to handle last <code>,</code> would be big pain. With this small change in syntax this is trivial to manage. And this is more important than machine generated code because is usually lot of easier to do it in Turing complete langue than very limited preprocesor.

blocks|key|258350|text|它使生成代码变得更容易，因为您只需要添加一行，并且不需要将添加最后一个条目视为特殊情况。在使用宏生成代码时，这一点尤其正确。有一种推动力试图从语言中消除对宏的需求，但许多语言确实是随着宏的出现而发展起来的。额外的逗号允许定义和使用下面这样的宏：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|258351|#define+LIST_BEGIN+int+a[]+=+{
#define+LIST_ENTRY(x)+x,
#define+LIST_END+};|code-block|syntax|javascript|258352|用法：|258353|LIST_BEGIN
+++LIST_ENTRY(1)
+++LIST_ENTRY(2)
LIST_END|258354|这是一个非常简单的示例，但宏通常使用此模式来定义调度、消息、事件或转换映射和表等内容。如果不允许在末尾使用逗号，我们需要一个特殊的：|258355|#define+LIST_LAST_ENTRY(x)+x|258356|使用起来会非常笨拙。|258357|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

It makes generating code easier as you only need to add one line and don't need to treat adding the last entry as if it's a special case. This is especially true when using macros to generate code. There's a push to try to eliminate the need for macros from the language, but a lot of the language did evolve hand in hand with macros being available. The extra comma allows macros such as the following to be defined and used:

<pre><code>#define LIST_BEGIN int a[] = {
#define LIST_ENTRY(x) x,
#define LIST_END };
</code></pre>

Usage:

<pre><code>LIST_BEGIN
 LIST_ENTRY(1)
 LIST_ENTRY(2)
LIST_END
</code></pre>

That's a very simplified example, but often this pattern is used by macros for defining things such as dispatch, message, event or translation maps and tables. If a comma wasn't allowed at the end, we'd need a special:

<pre><code>#define LIST_LAST_ENTRY(x) x
</code></pre>

and that would be very awkward to use.

blocks|key|2946093|text|因此，当两个人在不同分支上的列表中添加新项目时，Git可以正确地合并更改，因为Git是以行为单位工作的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2946094|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

So that when two people add a new item in a list on separate branches, Git can properly merge the changes, because Git works on a line basis.

Maybe I am not from this planet, but it would seem to me that the following should be a syntax error:
<pre><code>int a[] = {1,2,}; //extra comma in the end
</code></pre>
But it's not. I was surprised when this code compiled on Visual Studio, but I have learnt not to trust MSVC compiler as far as C++ rules are concerned, so I checked the standard and it is allowed by the standard as well. You can see 8.5.1 for the grammar rules if you don't believe me.
<img src="https://i.stack.imgur.com/kru1Y.png" alt="enter image description here" />
Why is this allowed? This may be a stupid useless question but I want you to understand why I am asking. If it were a sub-case of a general grammar rule, I would understand - they decided not to make the general grammar any more difficult just to disallow a redundant comma at the end of an initializer list. But no, the additional comma is explicitly allowed. For example, it isn't allowed to have a redundant comma in the end of a function-call argument list (when the function takes <code>...</code>), which is normal.
So, again, is there any particular reason this redundant comma is explicitly allowed?

int a[] = {1,2,}; Why is a trailing comma in an initializer-list allowed?

版本控制系统

Visual Studio

数据结构

服务器

编译器

Python

Perl

也许我不是来自这个星球，但在我看来，以下内容应该是一个语法错误：int a[] = {1,2,}; //extra comma in the end但事实并非如此。当这段代码在Visual Studio上编译时，我很惊讶，但我已经学会了不信任MSVC编译器，因为C++规则是相关的，所以我检查了标准，它的也是标准允许的。...

问int a[] = {1,2，}；为什么允许在初始化器列表中使用尾随逗号？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问int a[] = {1,2，}；为什么允许在初始化器列表中使用尾随逗号？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问int a[] = {1,2，}；为什么允许在初始化器列表中使用尾随逗号？
EN