in-class-initialization

I need some help understanding where this error is occurring: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions] This is the section of the code that it is coming from: typedef struct Hand { bool straight = false; bool flush = false; bool four = false; bool three = false; int pairs = 0; } Hand; That's not an error, it's a warning. It tells you that you're only allowed to initialize non-static members of a struct / class starting with the C++11 standard (so called because it was published in 2011). Before that, you weren't officially allowed to

In class initialization feature , which allows to initialize normal members inside the class itself, struct A { int a = 0; // error: ISO C++ forbids in-class initialization of non-const static member ‘a’ }; This is giving error in latest compiler gcc-4.6 (with -std=c++0x ). Has this feature made into the C++11 standard or gcc still doesn't support it ? Yes, that is legal in C++0x. There is an example of this at N3290 §12.6.2/8: struct C { /* ... */ int j = 5; // OK: j has the value 5 }; 来源： https://stackoverflow.com/questions/6482566/has-in-class-member-initialization-feature-made-into-c11

struct bitfield { int i = 0; // ok int j : 8 = 0; // error: lvalue required as left operand of assignment }; What is the correct syntax to initialize bit-fields using C++11 "in-class initialization" feature? What is the correct syntax to initialize bit-fields using C++11 "in-class initialization" feature? You cannot initialize bit-fields in-class. Paragraph 9.2 of the C++11 Standard specifies the grammar for class member declarators: [...] member-declarator: declarator virt-specifier-seq(opt) pure-specifier(opt) declarator brace-or-equal-initializer(opt) identifier(opt) attribute-specifier-seq

Consider the code: struct Foo { const char str[] = "test"; }; int main() { Foo foo; } It fails to compile with both g++ and clang++, spitting out essentially error: array bound cannot be deduced from an in-class initializer I understand that this is what the standard probably says, but is there any particular good reason why? Since we have a string literal it seems that the compiler should be able to deduce the size without any problem, similarly to the case when you simply declare an out-of-class const C-like null terminated string. sbabbi The reason is that you always have the possibility to