On Tue, 2010-03-30 at 21:17 +0100, Reece Dunn wrote: > On 30 March 2010 20:46, Murray Cumming <[email protected]> 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 -- [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
