Hi, The following code, compiled with -std=c++03 option, emits a warning instead of an error. Regards, Fernando. //Begin code #include <string> #include <utility> void foo( std::string ) {} void foo( std::pair<std::string, std::string> ) {} int main( /* int argc, char* argv[] */ ) { foo( {"k0", "v0"} ); return 0; } // End code #g++ -std=c++03 gcc_warning.cpp gcc_warning.cpp: In function 'int main()': gcc_warning.cpp:9:5: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default] gcc_warning.cpp:9:20: error: call of overloaded 'foo(<brace-enclosed initializer list>)' is ambiguous gcc_warning.cpp:9:20: note: candidates are: gcc_warning.cpp:4:6: note: void foo(std::string) gcc_warning.cpp:5:6: note: void foo(std::pair<std::basic_string<char>, std::basic_string<char> >)
Seems on purpose to me. Of course changing the warning to an error would be trivial. Maybe Jason can comment on why we have a warning here.
There is -pedantic-errors if you want an error.
(In reply to comment #2) > There is -pedantic-errors if you want an error. Precisely.
For other features of C++11 don't need -pedantic-errors to emit an error. See.. #include <string> void foo( std::string && str ) {} int main( /* int argc, char* argv[] */ ) { foo( "k0" ); return 0; } #g++ -std=c++03 gcc_warning.cpp gcc_warning.cpp:3:23: error: expected ',' or '...' before '&&' token It doesn't seem consistent. What is the criteria?
(In reply to comment #4) > For other features of C++11 don't need -pedantic-errors to emit an error. [...] > It doesn't seem consistent. > What is the criteria? Allowing {} is a rather isolated extension that doesn't interfere much with anything. Rvalue reference is perhaps the worst example you could pick as it changes the behavior all over the place and can easily break code. I don't know if there are official criteria, the choices may be questionable, but I don't see that it matters that much...
(In reply to comment #5) > (In reply to comment #4) > > For other features of C++11 don't need -pedantic-errors to emit an error. > [...] > > It doesn't seem consistent. > > What is the criteria? > > Allowing {} is a rather isolated extension that doesn't interfere much with > anything. Rvalue reference is perhaps the worst example you could pick as it > changes the behavior all over the place and can easily break code. I don't know > if there are official criteria, the choices may be questionable, but I don't > see that it matters that much... I got it. Thanks!