Re: gtkmm and C++0x

[Murray Cumming <murrayc murrayc com>]

On Tue, 2010-03-30 at 21:17 +0100, Reece Dunn wrote:
> On 30 March 2010 20:46, Murray Cumming <murrayc murrayc com> wrote:
> > On Tue, 2010-03-30 at 21:18 +0200, Mark Roberts wrote:
> >> I wouldn't want gtkmm to drop compatibilty with my old gcc just
> >> because
> >> there is a newer gcc available that I know I'm not going to install.
> >
> > We don't know of any reason that we would need to drop support.
> >
> > I'm mostly just asking for people to
> > a) Check that gtkmm builds with C++0x.
> 
> C++0x should be backward compatible with C++98/03.
> 
> > b) Check that example code works when it uses C++0x features, and check
> > if that suggests any need for improvements in the gtkmm API.
> 
> Likewise, the examples should work unmodified.

I know. I'd like someone to check.

> > c) Explore what C++0x features, if any, we might want to use in the API,
> > which might require dropping support.
> 
> C++0x language features that should be useful:
>   1/ auto, esp. in for loops over iterator ranges -- this should just
> be internal implementation/external usage, no API/ABI breakage [1];
>   2/ rvalue references for speeding up returning containers/complex
> types by value -- this should work without modification [1];
>   3/ lambda for signal/slot handlers -- this should work without modification;
>   4/ variadic template parameters for tuple and function/bind types
> (signal/slot functors) -- better support for N-ary template arguments;
>   5/ scoped and/or sized enumeration types -- better named/scoped
> enumerations -- gtk::justification::left;
>   6/ delagating constructors -- simplify handling of default
> arguments/special types, like in Java and C#;
>   7/ ???
> 
> [1] There will be the usual ABI breakage when using a newer version of
> standard types (std::string, std::vector, ...).
> 
> - Reece


-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com