Re: Re: gtkmm and C++0x

[american communist party gmail com]

Its going to be quite a while before 0x is adopted into all the tools we all care about. Even so, it offers some pretty attractive features. I'll be sand boxing a lot of code to play with it.  

On Mar 30, 2010 12:36pm, michi7x7 <mailing-lists michi7x7 de> wrote:
> 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 Hodappjames 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 Cummingmurrayc 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  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
> 
>    
> 
> 
> _______________________________________________
> 
> gtkmm-list mailing list
> 
> gtkmm-list gnome org
> 
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>