By Armen Tsirunyan

2011-08-12 16:36:30 8 Comments

Maybe I am not from this planet, but it would seem to me that the following should be a syntax error:

int a[] = {1,2,}; //extra comma in the end

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.

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 ...), which is normal.

So, again, is there any particular reason this redundant comma is explicitly allowed?


@Scott Langham 2018-04-23 12:15:49

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:

#define LIST_BEGIN int a[] = {
#define LIST_ENTRY(x) x,
#define LIST_END };



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:

#define LIST_LAST_ENTRY(x) x

and that would be very awkward to use.

@Yankes 2018-04-20 20:55:41

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

int a [] = {
#ifdef A
    1, //this can be last if B and C is undefined
#ifdef B
#ifdef C

Adding macros to handle last , 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.

@Shafik Yaghmour 2015-10-19 11:59:16

I am surprised after all this time no one has quoted the Annotated C++ Reference Manual(ARM), it says the following about [dcl.init] with emphasis mine:

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. [...]

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

and we can go to the C99 rationale to see why this was allowed in C and it says:

K&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.

@Nikos Athanasiou 2015-07-30 14:16:59

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" :

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? */

we read :

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

... to me this makes more sense

@supercat 2015-08-01 19:40:58

The prohibition against the comma in the enum case is somewhat interesting, since that's the case where the missing comma would pose the least ambiguity. Given struct foo arr[] = {{1,2,3,4,5}, {3,4,5,6,7}, }; there are two sensible meanings the language could assign: create a two-element array, or create a three-element array where the last item has default values. If C had adopted the later interpretation, I could see forbidding enum foo {moe, larry, curly, }; on the principle that there should only be one way to write the statement (without the comma), but...

@supercat 2015-08-01 19:44:11

...given that C is willing to ignore the comma in a case where it could reasonably have been (but wasn't) assigned a significant meaning (which would be a strong argument in favor of forbidding it there) it's curious that it isn't willing in a case where the comma couldn't have a meaning [even if one interpreted enum foo {moe,,larry,curly,}; as skipping a number between moe and larry, it wouldn't generally matter whether the trailing comma was processed or ignored. The only case where it could matter would be if the last item was the maximum value for its declared type, and that...

@supercat 2015-08-01 19:44:39

...could be handled by simply saying that overflow which occurs following the last assigned enumeration value should be ignored.

@Nikos Athanasiou 2015-08-05 12:43:30

@supercat There are languages, like C#, where a priori design research goes as far as considering IDE features and integration when devoloping the language. C was not (and couldn't have been) one of these languages.

@supercat 2015-08-05 14:57:26

Even with languages like C#, changing design objectives have resulted in some pretty severe design inconsistencies. For example, the language refrained from supporting any form of return-type overloading for normal methods and operators (even though the underlying framework could support it) because it was seen as contrary to the goal of having a simple-to-compile language, but lambda evaluation includes type inference rules whose resolution is NP-complete. Adding new method/operator overloading rules might break existing code (though I think good rules could minimize such danger)...

@supercat 2015-08-05 15:01:48

...but I don't see such issues in C's trailing-comma rules. IMHO, one of the major factors in deciding what to allow/forbid should be whether people who generally knew a language but not a particular feature would likely to incorrectly guess that feature's meaning. By that standard, int foo[] = {1,2,}; is much more dangerous than enum {LARRY, CURLY, };, and it is unlikely that the meaning of any existing code (including code allowed via compiler extensions) would change mening if the latter were made legitimate.

@Nikos Athanasiou 2015-08-05 15:18:23

@supercat All your observations make a really strong point

@Konrad Borowski 2014-05-10 16:56:38

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.

#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++) {
        std::cout << messages[i] << std::endl;

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

Stack Overflow
Super User
Server Fault

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.

#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++) {
        std::cout << messages[i] << std::endl;

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

Stack Overflow
Server FaultSuper User

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 - 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 wouldn't want to waste four hours debugging something, until you would find the comma is the cause of your problems.

@zhi_jian 2011-08-18 01:10:29

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<

@Thomson 2014-09-18 08:29:55

Is this a bug for VC6 which is not conformant with the standard?

@Iravanchi 2011-08-16 21:03:01

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 enum definition.

@amoss 2011-08-16 17:41:54

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:

int ints[] = {

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

Then your buddy edits it, adding to the end:

int ints[] = {

And you simultaneously edit it, adding to the beginning:

int ints[] = {

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.

@Jon Skeet 2011-08-12 16:39:46

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:

int a[] = {

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

output("int a[] = {");
for (int i = 0; i < items.length; i++) {
    output("%s, ", items[i]);

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

@Ryan 2011-08-12 20:43:12

This is especially if you were using macros to add items to arrays. Using macros don't have the smarts to distinguish when not to add a comma, or rather adding such logic makes macros inherently more complex.

@Kevin Panko 2011-08-12 21:05:07

Also, when using an VCS, the "diff" between two versions is cleaner since only one line changes when an item is added or removed.

@Néstor Sánchez A. 2011-08-13 00:20:56

If the justification is to make code generation simpler, then why not adopt the no parenthesis style of some funcional languages? and why not to infer all types? and remove the semicolons? and so on. I think the real reason was a very subjective and unfortunate criteria of the language designers.

@Jon Skeet 2011-08-13 05:59:38

@Néstor: Why "unfortunate"? What's the downside here? Just because some consideration has been given to code generation (and easy manipulation) for one tiny part of the language doesn't mean it has to be the primary motivation behind all decisions in the language. Type inference, removal of semi-colons etc have huge implications for the language. You're setting up a false dichotomy here, IMO.

@Néstor Sánchez A. 2011-08-13 22:43:17

Unfortunate because is inconsistent with other rules such as commas between method arguments, why the code-generation guys didn't get "helped" there? My reference to type inference, removal of semi-colons, etc. were to put an exaggerated example of a great help for code-generation. In other words, IMHO, or the language is fully consistent or is fully code-generation oriented.

@Jon Skeet 2011-08-13 22:47:25

@Néstor: That's where pragmatism wins over dogmatism: why does it have to be fully one thing or fully the other, when it's more useful to be a mixture of both? How does it actually get in the way, being able to add a comma at the end? Is this an inconsistency which has ever impeded you in any sense? If not, please weigh that irrelevant inelegance against the practical benefits of allowing a comma at the end.

@Chris McGrath 2011-08-14 02:10:11

its supported in a number of other languages besides c++ as well i know that php and c# support this so its not a c++ only thing

@h0b0 2011-08-15 11:21:13

I once stumbled across this issue when I wrote a script generating C code describing a 3D-Model and was happy that I didn't have to handle the last entry separately.

@Mrchief 2011-08-17 04:09:57

Generating code - can we say its done 10% or less times; rest of the time it involves typing in code. Statistically significant or not, those ferocious coders who blast off 100s of characters per minute, cannot afford to type in 2 more (or 20 more for that matter) characters? I'm not complaining, but this justification seems odd. I think it makes life easy on someone else's side, MS maybe?

@Jon Skeet 2011-08-17 05:17:37

@Mrchief: It's not a matter of typing rate - it's a matter of simplicity, when copying, removing or reordering items. It made my life simpler just yesterday. With no downside, why not make life easier? As for trying to point the finger at MS, I strongly suspect this has been in C since before Microsoft even existed... You say this justification seems odd, but I bet it benefits thousands of developers across hundreds of companies every single day. Isn't that a better explanation than looking for something that benefits compiler writers?

@Mrchief 2011-08-17 05:53:11

Totally with you, my thought is, why not make life easier in other places too? As a sidenote and a bit ironically, another MS product totally despises the trailing comma. :)

@Jon Skeet 2011-08-17 06:02:08

@Mrchief: I suspect it wouldn't be nearly as useful in other places - because most other places don't use a homogeneous list of items. For example, for method calls, reordering parameters is something which generally takes a lot more care due to the type system. The position makes a semantic difference, not just an order-of-appearance difference. (This doesn't hold as much water for named arguments, of course.) It feels like this was a single "let's put it in for this case for pragmatic reasons, but keep the language itself simpler elsewhere" decision.

@Mrchief 2011-08-17 14:23:34

Well, I was referring to other things, such as being able to say: public property int Index; (for auto-implemented properties primarily) which is much easier to type in (less chars, all in same row), more readable than ugly public int Index { get; set; }; and I guess tad easier for code generation as well.

@Jon Skeet 2011-08-17 14:26:13

@Mrchief: Introducing new keywords after release is a tricky business. It's possible that this wouldn't cause any problems (like other contextual keywords), but I'm not entirely sure... and how would you make a public "getter" with a private "setter" that way? I wouldn't want to have two different syntaxes for it... (Personally I wish field-like events were declared as public event EventHandler Foo { add; remove; }; to make them clearer, but there we go...)

@Roy Tinker 2011-11-17 18:21:55

"another MS product totally despises the trailing comma" -- I think Mrchief was really talking about object and array literals in IE6, IE7, and IE8 too IIRC.

@Ferruccio 2011-12-19 20:08:37

This was in K&R C.

@Nikos Athanasiou 2015-07-30 14:27:04

@NéstorSánchezA. I posted an answer on this rationale, as expressed in "Deep C secrets"

@supercat 2015-08-01 19:36:35

I wonder if any languages use item-intiator or statement-initiator characters? If e.g. a language required each item of a list, including the first, to be preceded by a colon, then adding items to a list anywhere, whether at the beginning or end, would pose no problem, and in cases where an item or statement needed to span multiple lines, the lack of an item-initiator character on the next line might be more conspicuous than the lack of an item-terminator or item-separator at the end of the previous line.

@djconnel 2015-10-07 01:45:40

This reminds me of the Oxford Comma debate. In any case, especially for matrix definitions, I think allowing the comma is much better: each line has a well-defined index-independent syntax. This is coding, not English!

@Shafik Yaghmour 2015-11-05 21:26:09

@Mrchief the annotated C++ reference manual says this came from C and the C99 rationale which I quote in my answer below says provides flexibility in adding or deleting members from an initializer list, and simplifies machine generation of such lists.

@Mrchief 2015-11-05 21:38:59

@RoyTinker: Spot on!

@Louis 2011-08-12 23:17:11

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?

#include <stdio.h>
#include <stdlib.h>

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

    return EXIT_SUCCESS

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?

@Giorgio 2011-08-18 06:19:01

There are languages (e.g. Pascal) that allow that. I.e. you have to choose between ; as a terminator (C) or as a separator (Pascal). Same for ','. It would be ok for me if ',' is a terminator, but then {1, 2, 3} must be a syntax error.

@Thomas Bonini 2011-08-12 18:37:15

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 & 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

@Peter C 2011-08-12 21:12:40

JavaScript's "arrays" (which are just objects with a magical length property) are rather unusual anyway: var x = [,,,] is legal (except in IE < 9, but the spec says it's legal)

@Dereleased 2011-08-12 21:59:10

According to the ECMAScript specification, it's perfectly valid; in theory it should work in any browser that implements JavaScript according to the said specification, particularly the part of the specification found here.

@kgadek 2011-08-12 22:44:52

Unfortunately JavaScript is all about making apps for the public. So no, it's not perfectly valid when ~50% users would have problems using your app. And yes, if I could I'd ban IE < 9 -- just too much hours spend on just making good code working there...

@Thomas Bonini 2011-08-12 22:48:31

@Dere: yes, I said as much in my answer =)

@Chris McGrath 2011-08-14 02:14:14

@Dereleased microsoft invents its own specifications and commands that other abide at least that mentality is changing (thank god)

@Giorgio 2011-08-18 06:17:22

@Andreas Bonini: The problem you describe can be solved by running a syntax checker on your code before shipping.

@Gene Bushuyev 2011-08-12 16:47:58

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.

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

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.

@Dereleased 2011-08-12 21:54:06

I disagree completely; [It is my opinion that] it has found its way into many languages created long after C precisely because it is advantageous for the programmer to be able to shift around the contents of the array, comment out lines willy-nilly, and so on, without having to worry about silly transposition-induced syntax errors. Are we not already stressed enough?

@Gene Bushuyev 2011-08-12 22:06:35

@Dereleased -- by the same logic, why shouldn't trailing (anything) be allowed, how about int a = b + c +; or if(a && b &&); it will be easier to just copy-and-paste anything at the end and easier to write code generators. This issue is both trivial, and subjective, in such cases it's always good to do what's best for the code reader.

@Giorgio 2011-08-18 06:15:50

@Gene Bushuyev: Exactly! I often have long expressions with + or &&, with the operator at the end of the line and, of course, I have to spend some extra time when I want to remove the last operand of the expression. I think this comma syntax is really odd!

@Sune Rasmussen 2011-11-22 09:25:50

@GeneBushuyev - I disagree on those. While allowing trailing commas in arrays and the like is a bug-removing feature and makes your life easier as a programmer, I would for the pure sake of readability take measures to remove trailing AND (&&) statements, plusses and other miscellaneous operators from conditional statements. It's just plain ugly, IMO.

@Christian Mann 2016-06-04 14:12:15

Regarding the && operator, sometimes I do conditionals like if (true \n && b1 \n && b2) so that I can add and remove lines as I need to.

@Maxim Egorushkin 2011-08-12 16:46:58

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


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

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 str.join() function:

print("enum Items {")

@Fredrik Pihl 2011-08-12 16:41:40

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.

@vcsjones 2011-08-12 16:40:57

Ease of use for the developer, I would think.

int a[] = {
            2, /*line I could comment out easily without having to remove the previous comma*/

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.

@Mark B 2011-08-12 16:40:52

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.

@Vlad 2011-08-12 16:40:47

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

Imagine the following code:

int a[] = {
   //3, // - not needed any more

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.

@Skilldrick 2011-08-12 16:39:52

It's useful if you do something like this:

int a[] = {
  3, //You can delete this line and it's still valid

@Jarred Sumner 2011-08-14 02:54:46

I'm surprised C++ has this, and many other languages don't (i.e Javascript)

@Sean Fujiwara 2011-08-14 03:43:42

JavaScript supports this syntax: var a = [1, 2,];, so do most other languages I know... ActionScript, Python, PHP.

@Skilldrick 2011-08-15 10:30:57

@Sean That'll cause a parse error in IE JavaScript, so beware!

@Sean Fujiwara 2011-08-16 02:06:17

It doesn't for me in IE9. But it does do something strange... it creates a null element. I will beware.

@Skilldrick 2011-08-16 09:57:29

@Sean Sorry, you're correct - it's not a parse error in IE, but it will insert an extra element set to undefined.

@Bruno Brant 2011-08-16 17:07:58

C# also allows this in some cases.

@Mechanical snail 2011-08-29 05:37:41

@Sean Fujiwara: Mathematica has the same issue.

@Konrad Borowski 2014-05-12 15:37:59

@Skilldrick: Well, technically it won't. Before ES5, the language didn't support trailing comma. However, the empty array element was undefined. Therefore, in JavaScript you can write [, 2]. Yes, it's completely pointless, but it works.

@Timmmm 2017-01-19 10:01:24

Most frustratingly, JSON doesn't support this syntax.

@Oliver Charlesworth 2011-08-12 16:39:34

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

int a[] = {

simply becomes:

int a[] = { 

at a later date.

@Giorgio 2011-08-12 20:59:05

I do not think making editing slightly faster is a good reason for messing up the syntax. IMHO this is just another weird C++ feature.

@Oliver Charlesworth 2011-08-12 21:01:59

@Giorgio: Well, it's inherited from C. It's entirely possible that it's just an oversight in the original language specification, that happens to have a useful side-effect.

@Giorgio 2011-08-12 21:16:53

Ok, I didn't know that it comes from C. I just checked that it is allowed in Java, too. It feels kind of weird though: in my intuition the comma is a separator not a terminator. Furthermore, it is possible to omit the last comma. So, is it a terminator, a separator, or both? But OK, this feature is available and it is good to know.

@Dereleased 2011-08-12 21:51:01

@Giorgio - source code is for humans, not machines. Little things like this to keep us from making simple transposition errors are a blessing, not an oversight. For reference, it also works this way in PHP and ECMAScript (and therefore JavaScript and ActionScript), although it is invalid in JavaScript object notation (JSON) (e.g. [1,2,3,] is OK but {a:1, b:2, c:3,} is not).

@Grokys 2011-08-12 23:32:13

@Giorgio - I'd say that rather than messing up the syntax, this improves the syntax. I can't count the number of times I've been glad you can do this.

@Dan Diplo 2011-08-13 08:46:56

It's also allowed in the latest C# specification

@Giorgio 2011-08-18 06:10:00

@Groky: The more I think about it the more I am convinced that the syntax of a programming language should be as simple and consistent as possible and with as few exceptions as possible: this makes it easier to learn the language (fewer rules to remember). The advantage of saving one or two keystrokes when adding / removing an item to / from a list (which, by the way, I do not do that often compared to the total amount of time I spend coding) seems rather trivial to me compared to having a clearly defined syntax.

@Grokys 2011-08-18 10:54:04

@Giorgio: And this is consistent: "foo = 1," wherever in the array that entry is.

@Nikos Athanasiou 2015-07-30 14:30:01

@Giorgio I posted an answer considering this, as found in the book "Deep C secrets"

Related Questions

Sponsored Content

10 Answered Questions

[SOLVED] Is there still a reason to use `int` in C++ code?

  • 2018-02-11 07:38:36
  • InsideLoop
  • 19276 View
  • 180 Score
  • 10 Answer
  • Tags:   c++

11 Answered Questions

[SOLVED] Why is f(i = -1, i = -1) undefined behavior?

1 Answered Questions

[SOLVED] Why are empty declarations allowed?

  • 2017-01-26 19:23:59
  • Leandros
  • 113 View
  • 1 Score
  • 1 Answer
  • Tags:   c language-lawyer

1 Answered Questions

[SOLVED] How to remove commas and parenthesis from function calls

3 Answered Questions

[SOLVED] Macro Expansion: Argument with Commas

1 Answered Questions

[SOLVED] Rationale for [dcl.constexpr]p5 in the c++ standard

2 Answered Questions

3 Answered Questions

[SOLVED] C++ Preprocessor Standard Behaviour

Sponsored Content