Re: gtkmm and C++0x

[michi7x7 <mailing-lists michi7x7 de>]

Probably because gcc hasn't already included the full standard? Because 
of this, programs which used it would not work properly.
GCC will include it, when the Standard is (nearly) completely supported.
> > I guess what I'm asking is how big a deal is it if gtkmm dropped c++98 support when c++0x comes out? Could we do it at gtkmm 3.0? Do the times line fit?
> >      
> The issue is gtkmm 3.0 will probably be released in the same time as
> gtk 3.0 (in almost 6 months). But if we break the ABI/API we have to
> wait than all officially supported compilers implement fully c++0x.
> But this won't happen in the next 6 months, so we can't use c++0x in
> gtkmm 3.0.
>
> I think my solution is good because we can use the standard we want.
> And when the time will be right (gtkmm 4 ?), we will be able to remove
> the old c++98 code easily.
>
> For the work to keep two code, i don't think it will increase a lot
> the maintenance.
>
>    
> > 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.
>
> ------------
> Fabien Parent
>
>
>
> On Tue, Mar 30, 2010 at 19:50, Jim Hodapp<james hodapp gmail com>  wrote:
>    
> > Not that my opinion matters very much because I haven't contributed any code to the core of gtkmm, but I agree with Chris on his point here. I think that gtkmm should move to c++0x fully when it comes out and should drop the c++98 support. It will get very confusing to have things start to mix otherwise.
> >
> > Jim
> >
> >
> > On Mar 30, 2010, at 1:36 PM, Christopher Harvey wrote:
> >
> >      
> > > The way I understand it, when c++0x comes application developers will want to use it. If gtkmm doesn't support the new standard then there will be an odd mix of shared_ptrs and auto's for example. Is c++0x even backward compatible with 98? I'm not a gtkmm developer but it sounds like Fabien's idea below would mean writing and maintaining 2 version of gtkmm in the same file. I guess what I'm asking is how big a deal is it if gtkmm dropped c++98 support when c++0x comes out? Could we do it at gtkmm 3.0? Do the times line fit?
> > >
> > > Fabien Parent wrote:
> > >        
> > > > Hi,
> > > > It would be great to see gtkmm start using some c++0x features. I
> > > > think the best would be to keep compatibility with c++ 98 like boost
> > > > did.
> > > >
> > > > We can find if the user is using c++98 or c++0x by looking if the
> > > > macro __GXX_EXPERIMENTAL_CXX0X__ has been defined by the gcc's
> > > > preprocessor.
> > > >
> > > > For example:
> > > > #if defined(__GXX_EXPERIMENTAL_CXX0X__)
> > > > // c++0x
> > > > #else
> > > > // c++98
> > > > #endif
> > > >
> > > > Fabien Parent
> > > >
> > > >
> > > >
> > > > On Tue, Mar 30, 2010 at 16:58, Murray Cumming<murrayc murrayc com>  wrote:
> > > >
> > > >          
> > > > > On Tue, 2010-03-30 at 16:48 +0200, Daniel Elstner wrote:
> > > > >
> > > > >            
> > > > > > Hi,
> > > > > >
> > > > > > Am Dienstag, den 30.03.2010, 16:19 +0200 schrieb Murray Cumming:
> > > > > >
> > > > > >
> > > > > >              
> > > > > > > It would be nice if someone played with using these new features in
> > > > > > > gtkmm. For intsance, create a git branch and try to replace use of
> > > > > > > Glib::RefPtr<Thing>  with auto wherever possible.
> > > > > > >
> > > > > > >                
> > > > > > Well, that would mainly be relevant for code using the gtkmm API.  I.e.
> > > > > > our examples and stuff.
> > > > > >
> > > > > >              
> > > > > Yes, we have lots of code in gtkmm-documentation/examples (make check,
> > > > > to build it) that should be branched to try stuff.
> > > > >
> > > > >
> > > > >            
> > > > > > For the time being I see no compelling reason to break compatibility
> > > > > > with C++ 98 in the library code itself.  However, I'm going to adopt
> > > > > > C++0x in my application code as soon as it can reasonably be done.
> > > > > >
> > > > > >              
> > > > > --
> > > > > murrayc murrayc com
> > > > > www.murrayc.com
> > > > > www.openismus.com
> > > > >
> > > > > _______________________________________________
> > > > > gtkmm-list mailing list
> > > > > gtkmm-list gnome org
> > > > > http://mail.gnome.org/mailman/listinfo/gtkmm-list
> > > > >
> > > > >
> > > > >            
> > > > _______________________________________________
> > > > gtkmm-list mailing list
> > > > gtkmm-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gtkmm-list
> > > >
> > > >          
> > > _______________________________________________
> > > gtkmm-list mailing list
> > > gtkmm-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/gtkmm-list
> > >        
> > _______________________________________________
> > gtkmm-list mailing list
> > gtkmm-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtkmm-list
> >
> >      
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>