Re: gtkmm and C++0x

[Fabien Parent <parent f gmail com>]

On Tue, Mar 30, 2010 at 22:35, Daniel Elstner
<daniel kitta googlemail com> wrote:
> Hi,
>
> Am Dienstag, den 30.03.2010, 20:37 +0200 schrieb Fabien Parent:
>
>> For the work to keep two code, i don't think it will increase a lot
>> the maintenance.
>
> OK, I will repeat myself: I don't see any glaring need to modify our API
> to use C++0x features.  Most of the C++0x features will work just fine
> on top of an API that is C++ 98 compatible.  There may be a few places
> here and there where an additional piece of glue for C++0x may make
> sense, but the bulk of the API is not going to be affected.
>
>> > There is a standard way to do that once the standard is out, which is to
>> > check the numeric value of the __cplusplus macro.
>>
>> In fact, gcc doesn't define the value of the macro, so it get the
>> default value of 1.
>> If gcc was following the standard it would be possible to write this:
>>
>> #if __cplusplus > 199711L
>> // c++0x
>> #else
>> // c++98
>> #endif
>>
>> But it's not. I hope others compilers follow the standard more closer.
>
> Dude, the standard has not even been released yet! :-)
>
> I think this is all much ado about nothing.  Adopting C++0x goodies is
> not going to require a redesign of gtkmm.  The changes I have in mind as
> proposals for gtkmm 3 go much further than anything C++0x might do to
> our API. :-)

__cplusplus is not something new from c++0x, it is already there in c++98.
Here come a quote from the c++ 98 standard paper:
"_ _cplusplus The name _ _cplusplus is defined to the value 199711L
when compiling a C++
   translation unit."
What I said is still true: gcc doesn't follow the c++98 standard
closely. At least in gcc 4.4 shipped in debian sid.