> On 18 Sep 2017, at 09:25, Ville Voutilainen <[email protected]> 
> wrote:
> 
> On 18 September 2017 at 10:02, Lorn Potter <[email protected]> wrote:
>>>> 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.
> 
> Do we still really support targets that don't support C++11?

No, we don't. We still support some compilers that have incomplete C++11 
support (VS2013 comes to my mind). But at least override and nullptr are now 
supported everywhere. I am in favour of doing a global search and replace of 
Q_DECL_OVERRIDE with override etc, as it does improve readability of our code 
base a lot.
> 
>> 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.
> 
> If you have more than one constructor that set a member to the same
> value, it's arguably simpler and less error-prone
> to use a member initializer.

I also think that we should be using member initialisers when writing new code 
(or when refactoring existing code). But doing a global search/replace of 
existing code might lead to subtle errors as it's easy to miss the rare case 
when different constructors initialise members differently.

Cheers,
Lars

_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to