Hi all,
Now that we can use C++11 in trunk (yeah!), what are the best practices? Are there parts of C++11 we still want to avoid?
I started to think about this as I noticed in the code some places 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
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
According to the wiki, we can't use anything: http://wiki.inkscape.org/wiki/index.php/C%2B%2B11
So please do not use C++11, or do update the wiki page — :). Or mark it as outdated.
Sylvain
Le 13/08/2016 à 17:24, Alex Valavanis a écrit :
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
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
On Sat, Aug 13, 2016 at 11:17:29PM +0200, Sylvain Chiron wrote:
According to the wiki, we can't use anything: http://wiki.inkscape.org/wiki/index.php/C%2B%2B11
So please do not use C++11, or do update the wiki page — :). Or mark it as outdated.
Hi Sylvain, just wanted to pipe and say after quite some discussions back and forth we reached a decision to allow C++11 and switch to Gtk3 starting with 0.93. I see Alex has already updated the page you linked accordingly.
It is perhaps dangerous from a stability POV to change several major things at once rather than staging them one per release, but the fact that the 0.92 cycle has lasted so long and we've had to hold off on so many of these changes, we may need to treat 0.93 as more of an unstable devel release just to get things caught up.
So we may want to handle 0.92 as sort of a long term stable type release, and backport important fixes to it as much as possible.
Bryce
Sylvain
Le 13/08/2016 à 17:24, Alex Valavanis a écrit :
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
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
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
Le 18/08/2016 à 02:30, Bryce Harrington a écrit :
Hi Sylvain, just wanted to pipe and say after quite some discussions back and forth we reached a decision to allow C++11 and switch to Gtk3 starting with 0.93.
I know. Actually the purpose of my message was to remind everyone to keep the wiki up-to-date so that the developers can use it as a reference and are not misleaded.
Thanks for your details. -- Sylvain
On Sat, 2016-08-13 at 16:27 +0200, Tavmjong Bah wrote:
I started to think about this as I noticed in the code some places 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()
My thoughts on this are when the type is clear, it's good to use auto to avoid duplication. When the type is not, it makes things harder to figure out. So for instance this is a good use: auto foo = gtk_box_new(); But this would be bad: auto foo = doStuff(); But that also goes for naming the varriable, as this would make sense to me: auto doStuffSuccessful = doStuff(); So it is largely a feeling thing, I think it is useful but I also think it can be overused. Ted
participants (5)
-
Alex Valavanis -
Bryce Harrington -
Sylvain Chiron -
Tavmjong Bah -
Ted Gould