| Message ID | 5177EF87.4000003@oracle.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Apr 24, 2013 at 9:43 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote: > Hi, > > I believe this is all we need in order to get the ball rolling in the > library for -std=c++1y. > > If we think it's conceptually clearer (no difference in practice, because > cxx11 == cxx0x), for the legacy C++0x macro we could also do: > > if (cxx_dialect >= cxx0x && cxx_dialect < cxx1y) > cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX0X__"); > > I'm finishing testing the below on x86_64-linux. > > Thanks, > Paolo. > > /////////////////////// I prefer the patch as you posted it. I would like us to actually move to deprecate __GXX_EXPERIMENTAL_CXX0X__ in GCC-4.9 and remove it in the release after that. I don't think our support C++11 is still that experimental. we can't have experimental support for two C++ standards going on :-) Other implementations are thumping the chest about being C++11 feature complete for less than what we offer. Patch OK. -- Gaby
I would really rather avoid introducing another macro to be removed again later. Instead, let's use a value of __cplusplus greater than 201103L, perhaps 201300? Jason
On Wed, Apr 24, 2013 at 11:26 AM, Jason Merrill <jason@redhat.com> wrote: > I would really rather avoid introducing another macro to be removed again > later. Instead, let's use a value of __cplusplus greater than 201103L, > perhaps 201300? > > Jason yes, that makes sense, and even a better path forward. Hopefully, the next committee draft will have that value. -- Gaby
On 04/24/2013 12:48 PM, Gabriel Dos Reis wrote: > On Wed, Apr 24, 2013 at 11:26 AM, Jason Merrill <jason@redhat.com> wrote: >> I would really rather avoid introducing another macro to be removed again >> later. Instead, let's use a value of __cplusplus greater than 201103L, >> perhaps 201300? > > yes, that makes sense, and even a better path forward. > Hopefully, the next committee draft will have that value. We won't have a value for the next standard until we have a next standard, so let's just invent a value for now; presumably people will know better than to check for that invented value specifically. Jason
Hi, On 04/24/2013 06:55 PM, Jason Merrill wrote: > On 04/24/2013 12:48 PM, Gabriel Dos Reis wrote: >> On Wed, Apr 24, 2013 at 11:26 AM, Jason Merrill <jason@redhat.com> >> wrote: >>> I would really rather avoid introducing another macro to be removed >>> again >>> later. Instead, let's use a value of __cplusplus greater than 201103L, >>> perhaps 201300? >> >> yes, that makes sense, and even a better path forward. >> Hopefully, the next committee draft will have that value. > > We won't have a value for the next standard until we have a next > standard, so let's just invent a value for now; presumably people will > know better than to check for that invented value specifically. This "invention" scared me, that's why I didn't even propose it. Anyway, for the time being I'm going to simply revert what I committed earlier today. It would be great if somebody can implement the __cplusplus change as soon as possible. Thanks! Paolo.
On Wed, Apr 24, 2013 at 11:55 AM, Jason Merrill <jason@redhat.com> wrote: > On 04/24/2013 12:48 PM, Gabriel Dos Reis wrote: >> >> On Wed, Apr 24, 2013 at 11:26 AM, Jason Merrill <jason@redhat.com> wrote: >>> >>> I would really rather avoid introducing another macro to be removed again >>> later. Instead, let's use a value of __cplusplus greater than 201103L, >>> perhaps 201300? >> >> >> yes, that makes sense, and even a better path forward. >> Hopefully, the next committee draft will have that value. > > > We won't have a value for the next standard until we have a next standard, > so let's just invent a value for now; presumably people will know better > than to check for that invented value specifically. > > Jason > We can always try to convince the project editor to honor a tradition from the past where the editor would set the value of __cplusplus to a value that reflect the approval date of a working draft. This is purely editorial and he could exercise that discretion to help implementor do the right thing. That way, we don't have to way to have a standard. Of course, programmers should not test for equality of that value. -- Gaby
Index: c-family/c-cppbuiltin.c =================================================================== --- c-family/c-cppbuiltin.c (revision 198231) +++ c-family/c-cppbuiltin.c (working copy) @@ -713,8 +713,10 @@ c_cpp_builtins (cpp_reader *pfile) cpp_define (pfile, "__DEPRECATED"); if (flag_rtti) cpp_define (pfile, "__GXX_RTTI"); - if (cxx_dialect >= cxx0x) + if (cxx_dialect == cxx0x) cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX0X__"); + if (cxx_dialect >= cxx1y) + cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX1Y__"); } /* Note that we define this for C as well, so that we know if __attribute__((cleanup)) will interface with EH. */ Index: doc/cpp.texi =================================================================== --- doc/cpp.texi (revision 198231) +++ doc/cpp.texi (working copy) @@ -2319,6 +2319,13 @@ features likely to be included in C++0x are availa features are experimental, and may change or be removed in future versions of GCC. +@item __GXX_EXPERIMENTAL_CXX1Y__ +This macro is defined when compiling a C++ source file with the option +@option{-std=c++1y} or @option{-std=gnu++1y}. It indicates that some +features likely to be included in C++1y are available. Note that these +features are experimental, and may change or be removed in future +versions of GCC. + @item __GXX_WEAK__ This macro is defined when compiling a C++ source file. It has the value 1 if the compiler will use weak symbols, COMDAT sections, or Index: testsuite/g++.dg/cpp1y/cxx1y_macro.C =================================================================== --- testsuite/g++.dg/cpp1y/cxx1y_macro.C (revision 0) +++ testsuite/g++.dg/cpp1y/cxx1y_macro.C (working copy) @@ -0,0 +1,5 @@ +// { dg-options "-std=c++1y" } + +#ifndef __GXX_EXPERIMENTAL_CXX1Y__ +#error +#endif
Hi, I believe this is all we need in order to get the ball rolling in the library for -std=c++1y. If we think it's conceptually clearer (no difference in practice, because cxx11 == cxx0x), for the legacy C++0x macro we could also do: if (cxx_dialect >= cxx0x && cxx_dialect < cxx1y) cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX0X__"); I'm finishing testing the below on x86_64-linux. Thanks, Paolo. /////////////////////// /c-family 2013-04-24 Paolo Carlini <paolo.carlini@oracle.com> * c-cppbuiltin.c (c_cpp_builtins): Define __GXX_EXPERIMENTAL_CXX1Y__. /doc 2013-04-24 Paolo Carlini <paolo.carlini@oracle.com> * cpp.texi: Document __GXX_EXPERIMENTAL_CXX1Y__. /testsuite 2013-04-24 Paolo Carlini <paolo.carlini@oracle.com> * g++.dg/cpp1y/cxx1y_macro.C: New.