Op 18/09/2017 om 09:02 schreef Lorn Potter: >> On 15 Sep 2017, at 6:47 pm, Kevin Funk <kevin.f...@kdab.com> 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 don't get this. Wouldn't doing this do as much cleanup as is reasonably possible across the whole code base? How do you end up with a mixture then?
> >> >> 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. Qt already requires C++11. So no, we do not still want to target platforms that don't support C++11. > > 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. It is less error-phrone to initialize at the place of declaration, instead of in a different file. This gets worse if you have multiple constructors. So, naturally, we end up with uninitialized member variables, with all the mahem that may cause. André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
