diff mbox

[libcpp] Correctly define __cplusplus (PR libstdc++-v3/1773)

Message ID yddy5z2q3xt.fsf@manam.CeBiTec.Uni-Bielefeld.DE
State New
Headers show

Commit Message

Rainer Orth Aug. 9, 2011, 10:23 a.m. UTC
This patch achieves what all the previous ones have prepared: finally
defining __cplusplus correctly instead of the current 1.  I'm uncertain
if it's already appropriate to define the C++ 2011 value yet, but I've
kept it in the patch.

Of course this patch can only go in once all the prerequisite patches
are installed.

	Rainer


2011-03-07  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR libstdc++/1773
	* init.c (cpp_init_builtins): Define __cplusplus 19971L for C++ 98,
	201103L for C++ 0X.

Comments

Marc Glisse Aug. 9, 2011, 1:14 p.m. UTC | #1
On Tue, 9 Aug 2011, Rainer Orth wrote:

> This patch achieves what all the previous ones have prepared: finally
> defining __cplusplus correctly instead of the current 1.  I'm uncertain
> if it's already appropriate to define the C++ 2011 value yet, but I've
> kept it in the patch.

Hello,

I don't think we should define the C++ 2011 value yet. In my opinion, we 
should wait until:
1) the standard is official
2) gcc implements most of it: people will want to use __cplusplus as a 
test to know if they can use C++0X features, not if the compiler does some 
effort to implement half of them.

(of course that policy is to be decided by g++ and libstdc++ maintainers)
Jason Merrill Aug. 9, 2011, 8:11 p.m. UTC | #2
On 08/09/2011 09:14 AM, Marc Glisse wrote:
> I don't think we should define the C++ 2011 value yet. In my opinion, we
> should wait until:
> 1) the standard is official
> 2) gcc implements most of it: people will want to use __cplusplus as a
> test to know if they can use C++0X features, not if the compiler does
> some effort to implement half of them.

I'm of two minds about this, but I see that clang and edg still use 
199711L in C++0x mode, so let's stick with that for now.

Jason
Rainer Orth Aug. 10, 2011, 12:12 p.m. UTC | #3
Jason Merrill <jason@redhat.com> writes:

> On 08/09/2011 09:14 AM, Marc Glisse wrote:
>> I don't think we should define the C++ 2011 value yet. In my opinion, we
>> should wait until:
>> 1) the standard is official
>> 2) gcc implements most of it: people will want to use __cplusplus as a
>> test to know if they can use C++0X features, not if the compiler does
>> some effort to implement half of them.
>
> I'm of two minds about this, but I see that clang and edg still use 199711L
> in C++0x mode, so let's stick with that for now.

Ok, I just wanted to bring it up.  I'll resubmit with the 201103L change
removed once the other patches (tm etc. mangling and libstdc++) are
resolved.

Thanks.
        Rainer
Gabriel Dos Reis Aug. 10, 2011, 5:22 p.m. UTC | #4
On Wed, Aug 10, 2011 at 7:12 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Jason Merrill <jason@redhat.com> writes:
>
>> On 08/09/2011 09:14 AM, Marc Glisse wrote:
>>> I don't think we should define the C++ 2011 value yet. In my opinion, we
>>> should wait until:
>>> 1) the standard is official
>>> 2) gcc implements most of it: people will want to use __cplusplus as a
>>> test to know if they can use C++0X features, not if the compiler does
>>> some effort to implement half of them.
>>
>> I'm of two minds about this, but I see that clang and edg still use 199711L
>> in C++0x mode, so let's stick with that for now.
>
> Ok, I just wanted to bring it up.  I'll resubmit with the 201103L change
> removed once the other patches (tm etc. mangling and libstdc++) are
> resolved.

After the experience with C++98 implementation, I have also become two-minded
about this.  In the end I agree with Jason that we should just keep
the C++03 value
for the moment.
Marc Glisse Oct. 21, 2011, 7:11 p.m. UTC | #5
On Tue, 9 Aug 2011, Jason Merrill wrote:

> On 08/09/2011 09:14 AM, Marc Glisse wrote:
>> I don't think we should define the C++ 2011 value yet. In my opinion, we
>> should wait until:
>> 1) the standard is official
>> 2) gcc implements most of it: people will want to use __cplusplus as a
>> test to know if they can use C++0X features, not if the compiler does
>> some effort to implement half of them.
>
> I'm of two minds about this, but I see that clang and edg still use 199711L 
> in C++0x mode, so let's stick with that for now.

Note that at least clang now defines __cplusplus to its new C++11 value 
(in experimental C++0X mode only). Apparently they switched around last 
June and say they are not the only ones. So if you want to follow their 
lead...
Jason Merrill Oct. 21, 2011, 7:52 p.m. UTC | #6
On 10/21/2011 03:11 PM, Marc Glisse wrote:
> Note that at least clang now defines __cplusplus to its new C++11 value
> (in experimental C++0X mode only). Apparently they switched around last
> June and say they are not the only ones. So if you want to follow their
> lead...

Hmm, between that and the fact that 4.7 will in fact have almost all of 
the C++11 features, I think changing the value makes sense.

Jason
Mike Stump Oct. 21, 2011, 10:22 p.m. UTC | #7
On Oct 21, 2011, at 12:52 PM, Jason Merrill wrote:
> On 10/21/2011 03:11 PM, Marc Glisse wrote:
>> Note that at least clang now defines __cplusplus to its new C++11 value
>> (in experimental C++0X mode only). Apparently they switched around last
>> June and say they are not the only ones. So if you want to follow their
>> lead...
> 
> Hmm, between that and the fact that 4.7 will in fact have almost all of the C++11 features, I think changing the value makes sense.

Is there a plan on what the default language will be?  C is stuck in 1980, and will be forever.  Personally, I'd rather have g++ move up language standards by default, I'd rather make the move before 2023.
Gabriel Dos Reis Oct. 22, 2011, 12:16 a.m. UTC | #8
On Fri, Oct 21, 2011 at 5:22 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Oct 21, 2011, at 12:52 PM, Jason Merrill wrote:
>> On 10/21/2011 03:11 PM, Marc Glisse wrote:
>>> Note that at least clang now defines __cplusplus to its new C++11 value
>>> (in experimental C++0X mode only). Apparently they switched around last
>>> June and say they are not the only ones. So if you want to follow their
>>> lead...
>>
>> Hmm, between that and the fact that 4.7 will in fact have almost all of the C++11 features, I think changing the value makes sense.
>
> Is there a plan on what the default language will be?  C is stuck in 1980, and will be forever.  Personally, I'd rather have g++ move up language standards by default, I'd rather make the move before 2023.

I would like to see the default change too.  But for GCC-4.8 -- so that should
take care of Mike's worry :-)
Do we have a formal way to announce default change in upcoming release?
I think that would give enough "heads up", especially since C++11 with break ABI
compatibilty.
Jason Merrill Oct. 22, 2011, 4:40 a.m. UTC | #9
On 10/21/2011 06:22 PM, Mike Stump wrote:
> Is there a plan on what the default language will be?  C is stuck in 1980, and will be forever.  Personally, I'd rather have g++ move up language standards by default, I'd rather make the move before 2023.

I think it makes sense to change the default once C++11 support is 
mature, I'd guess in 4.9.

Jason
diff mbox

Patch

diff -r f20c297198b4 libcpp/init.c
--- a/libcpp/init.c	Sat Mar 12 10:48:29 2011 +0100
+++ b/libcpp/init.c	Sat Mar 12 10:51:07 2011 +0100
@@ -452,8 +452,12 @@ 
 	  || CPP_OPTION (pfile, std)))
     _cpp_define_builtin (pfile, "__STDC__ 1");
 
-  if (CPP_OPTION (pfile, cplusplus))
-    _cpp_define_builtin (pfile, "__cplusplus 1");
+  if (CPP_OPTION (pfile, lang) == CLK_CXX98
+      || CPP_OPTION (pfile, lang) == CLK_GNUCXX)
+    _cpp_define_builtin (pfile, "__cplusplus 199711L");
+  else if (CPP_OPTION (pfile, lang) == CLK_CXX0X
+      || CPP_OPTION (pfile, lang) == CLK_GNUCXX0X)
+    _cpp_define_builtin (pfile, "__cplusplus 201103L");
   else if (CPP_OPTION (pfile, lang) == CLK_ASM)
     _cpp_define_builtin (pfile, "__ASSEMBLER__ 1");
   else if (CPP_OPTION (pfile, lang) == CLK_STDC94)