> On 18 Sep 2017, at 09:37, André Somers <an...@familiesomers.nl> wrote: > > 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’m not sure what Lorn meant, but there are cases where you can’t do the initialization along with the declaration: for example bitfields. Or when the initialization needs to be different in different constructors. So as long as we accept that it will never be 100%, I think it doesn’t hurt to use it where we can. >>> 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). +1 yes please… I always do (1) in new code and strongly encourage it in code reviews, for a long time already. > 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. Yep; and the lazy reason to like it is that you don’t have to worry about keeping initialization in the same order as declaration, with all the $#@% warnings if you don’t. (If this pedantry is so important, why can’t it be automated? And now it finally is.) Slight downside: it’s going to make merges harder for a while. I guess we will do such wholesale changes only on dev branch? _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
