Patchwork [C++] Add __GXX_EXPERIMENTAL_CXX1Y__

login
register
mail settings
Submitter Paolo Carlini
Date April 24, 2013, 2:43 p.m.
Message ID <5177EF87.4000003@oracle.com>
Download mbox | patch
Permalink /patch/239219/
State New
Headers show

Comments

Paolo Carlini - April 24, 2013, 2:43 p.m.
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.
Gabriel Dos Reis - April 24, 2013, 2:57 p.m.
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
Jason Merrill - April 24, 2013, 4:26 p.m.
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
Gabriel Dos Reis - April 24, 2013, 4:48 p.m.
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
Jason Merrill - April 24, 2013, 4:55 p.m.
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
Paolo Carlini - April 24, 2013, 5:02 p.m.
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.
Gabriel Dos Reis - April 24, 2013, 6:07 p.m.
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

Patch

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