[Development] RFC: more liberal 'auto' rules?

Konstantin Tokarev annulen at yandex.ru
Tue Dec 22 14:25:11 CET 2015



22.12.2015, 15:48, "Bubke Marco" <Marco.Bubke at theqtcompany.com>:
> I think in the end we will look if it is easier to implement something similar. It's a tradeoff.
>
> On December 22, 2015 13:06:42 Konstantin Tokarev <annulen at yandex.ru> wrote:
>
>>  22.12.2015, 14:50, "Bubke Marco" <Marco.Bubke at theqtcompany.com>:
>>>  Clazy is nice but it's under GPL so it's not possible to integrate it in the creator clang code model. But I think we need something like clazy for the clang code model too.
>>
>>  I see at least 2 options how to integrate clazy:
>>
>>  1. Include it as a separate GPL-only plugin, users of commercial edition will be able to install it separately. If that's too cumbersome to separate this checks from code model, guard them with ifdefs so Clang plugin could be compiled as GPL or as LGPL
>
> I don't think it is feasible but you must ask lawyers about that.
>>  2. Just use it as external tool and parse its output.
>
> Sorry, this is not how the code models works.

I've meant to use it as static analyzer, not part of code model in this case.

 It would be much easier to reimplement the functionality of clazy.
>>>  ________________________________________
>>>  From: Development <development-bounces at qt-project.org> on behalf of Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
>>>  Sent: Tuesday, December 22, 2015 11:59 AM
>>>  To: development at qt-project.org
>>>  Subject: Re: [Development] RFC: more liberal 'auto' rules?
>>>
>>>  Il 22/12/2015 11:26, Ziller Eike ha scritto:
>>>>   So funny/unwanted behavior can occur both because one used the wrong explicit type, and because one used auto instead of an explicit type.
>>>
>>>  These shortcomings of auto are recognized in the community, but yes,
>>>  they're real and dangerous. Clazy [1] already has a warning for the
>>>  danger of auto with QStringBuilder, I guess it can be extended to other
>>>  cases.
>>>
>>>  N4035 [2] proposes general purpose workarounds ("operator auto",
>>>  specializations to std::decay, etc.) to address these issues.
>>>
>>>>   [1] https://github.com/KDE/clazy/blob/master/README
>>>>   [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf
>>>
>>>  My 2 c,
>>>  --
>>>  Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
>>>  KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
>>>  KDAB - The Qt Experts
>>>
>>>  _______________________________________________
>>>  Development mailing list
>>>  Development at qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/development
>>
>>  --
>>  Regards,
>>  Konstantin
>
> Sent from cellphone

-- 
Regards,
Konstantin



More information about the Development mailing list