Re: gtkmm and C++0x

[Daniel Elstner <daniel kitta googlemail com>]

Hi,

Am Mittwoch, den 31.03.2010, 12:51 +0200 schrieb michi7x7:

> > I had a discussion about this with Daniel once. One of the good uses
> > of auto would be avoid redundancy.
> > eg., Glib::RefPtr<Gtk::IconTheme>  icon_theme = Gk::IconTheme::get_default();
> > Here the return type is quite obvious and using auto makes sense to
> > make the code more readable by avoiding really long statements.
> >    
> But your IDE can't definitely know the type of this variable.

My IDE does not even know what variables are. :)  That aside, a smart
IDE with understanding of the language could of course know the type of
the auto variable, just as the compiler knows it.

> Even worse: if the gtkmm-Team decides to return Gtk::IconTheme* instead, 
> your "auto"-Type would be Gtk::IconTheme. Glib::RefPtr could have a 
> constructor, which takes a Glib::Object, so "normal" code would work, 
> but code using "auto" not.

Actually, it's the other way around.  Glib::RefPtr<> does currently have
an (explicit) constructor which initializes from a plain pointer, but it
does not take an additional reference.  Depending on whether your
hypothetical get_default() which returns a plain pointer acquires a
reference on the return type or not, your code may break in subtle ways.

Apart from that, coming up with scenarios where using "auto" is bad does
not invalidate the idea of "auto" in general.  Of course it can (and
will) be used inappropriately.

--Daniel