> On 15 Sep 2017, at 6:47 pm, Kevin Funk <[email protected]> wrote: > > (2) And maybe your request: > - Use C++11 member initialization where possible > (IOW: Run clang-tidy cppcoreguidelines-pro-type-member-init checker > on code base and apply all fixes)
But then files will begin to have a mixture of the two conventions, which is not necessarily a good thing. Wide scale changing of this is probably not a good idea. > > > I personally think that (1) would be useful (despite it costing us a lot of > code churn when doing the transition) because it's much easier to read > `nullptr` than `Q_NULLPTR`, or `override` instead of `Q_DECL_OVERRIDE` in > code. Other opinions may vary, but it's definitely more comfortable for > newcomers to read familiar C++ keywords than custom macros. > > I'd be willing to provide the patches for (1) and maybe even (2) if there's a > clear sentiment towards the change(s). > >> The section "Conventions for C++11 usage" in [1] states: >> >> "Note: This section is not an accepted convention yet. >> This section serves as baseline for further discussions." >> >> I'd like to push this discussion, because if code is converted to a new >> base, it should be clear to everyone HOW to do so. > > For new code the this should be a no-brainer, IMO. So +1 from my side. It really depends on the code, and where it is. Not all platforms/systems will support c++11 I suppose, and we might want to still target these. I am not up to date with all the platforms/targets, etc. But for new plugins that target a known platform that supports c++11, they can most likely use new conventions. Unless someone can come up with technical reasons the new c++11 member initialization is better than what is there now, I’d rather keep it the same as it is now. - Lorn Potter Developer, Maintainer QtSensors/QtSystemInfo _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
