<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 1:07 PM Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Sep 29, 2020 at 12:57 PM Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> wrote:<br>
><br>
> Side question, is there a technical reason to prefer this syntax over the = one?<br>
><br>
> The = is more readable to me, but that's a matter of experience I guess.<br>
> More generally, it would be nice to decide for one syntax and have a coherence over the source code.<br>
><br>
> Cheers,<br>
> Denis<br>
><br>
<br>
Hi Denis,<br>
<br>
I agree about the need for coherence, we currently have a mix of = ()<br>
and {} initialization.<br>
<br>
I'm not such an expert to tell you which is the best, but I've found<br>
this explanations quite convincing:<br>
<br>
<a href="https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es23-prefer-the--initializer-syntax" rel="noreferrer" target="_blank">https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es23-prefer-the--initializer-syntax</a><br>
<a href="https://stackoverflow.com/questions/18222926/why-is-list-initialization-using-curly-braces-better-than-the-alternatives" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/18222926/why-is-list-initialization-using-curly-braces-better-than-the-alternatives</a><br>
<br>
That is the reason why I switched to {} as my preferred method.<br>
<br>
Cheers<br>
<br>
> Le mar. 29 sept. 2020 à 11:55, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> a écrit :<br>
>><br>
>> Looks like cppcheck is not smart enough...<br>
>><br>
>> const double factor { std::pow( 10, - mPrecisionSpinBox->value() ) };<br>
>><br>
>> <a href="https://github.com/qgis/QGIS/pull/39079/checks?check_run_id=1181360827#step:4:1693" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/pull/39079/checks?check_run_id=1181360827#step:4:1693</a><br>
>><br>
>> --<br>
>> Alessandro Pasotti<br>
>> QCooperative:  <a href="http://www.qcooperative.net" rel="noreferrer" target="_blank">www.qcooperative.net</a><br>
>> ItOpen:   <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
>> _______________________________________________<br>
>> QGIS-Developer mailing list<br>
>> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
<br>
<br></blockquote><div><div dir="ltr"><div><div>There are certainly some advantages of {} (guessing since it wouldn't have been added to the standard otherwise).</div><div><br></div><div>However... We have been bitten by incompatibilities (compiler and/or c++ version) more than once. And the more I read about it, the more I am convinced that proper and conscious usage is not a simple task. See also the controversial discussion in the stackoverflow link Alessandro posted.<br></div><div>So far it has failed to convince me as an adequate mitigation for the problems it tries to solve.<br><br></div><div>Matthias</div></div></div> </div></div>
</div>