Hi Tav,
There is a potential advantage of using auto in place of simple return types, in that it protects us (to an extent) against upstream API changes if the return type of a function changes. A good example is when Gtk::HBox was deprecated in favour of its parent class Gtk::Box. It also makes things easier for us if we make changes to our own class design, as we no longer need to propagate changes in return types throughout the code.
AV
On 13 August 2016 at 15:27, Tavmjong Bah <tavmjong@...8...> wrote:
Hi all,
Now that we can use C++11 in trunk (yeah!), what are the bestpractices? Are there parts of C++11 we still want to avoid?
I started to think about this as I noticed in the code someplaces with perhaps over aggressive use of 'auto'. It seems to me that 'auto' should be reserved to places where it replaces a long, already unreadable iterator type. But it should not be used to replace simple types as this reduces the readability of the code, especially to someone not familiar with the code. For example, I don't see any benefit of replacing:
GtkWidget* mywidget = someFunction();
by
auto* mywidget = someFunction()
Tav
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel