On Tue, Mar 30, 2010 at 22:35, Daniel Elstner <[email protected]> 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. _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
