<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 10:41 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, May 26, 2015 at 10:28 AM, Richard <span dir="ltr"><<a href="mailto:legalize@xmission.com" target="_blank">legalize@xmission.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In article <CAENS6EvMeS=<a href="mailto:FUTf49-ar%2BzBSUr9BqfraSHuuGd%2B7xYRiuwDfhg@mail.gmail.com" target="_blank">FUTf49-ar+zBSUr9BqfraSHuuGd+7xYRiuwDfhg@mail.gmail.com</a>>,<br>
<span>    David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> writes:<br>
<br>
> I don't believe there's any documented (or commonly enforced implicit)<br>
> convention here.<br>
><br>
> I tend towards p/!p, personally. (one place where it's worth being more<br>
> explicit is in function arguments - "func(p)" where func takes a boolean is<br>
> a bit subtle, "func(p != nullptr)" seems better there, unless the names of<br>
> the function/p/etc are /really/ obvious)<br>
<br>
</span>Yes, I'm only talking about the case where a pointer compared to<br>
nullptr is in the conditional expression of an if statement.  I agree<br>
that it is a little too subtle when it is an implicit conversion to<br>
bool for a function argument.<br></blockquote></span><div><br>I doubt (but data could be used to sway me) there's sufficient convention one way or another to make it a check - but the thing about checks is that they can be used by people who feel they enforce what they want, and not used by those who don't, so the bar is pretty low to what can be implemented as a check - and teams/products/etc can opt in to those that are consistent.<br></div></div></div></div></blockquote><div><br></div><div>I believe when I did the conversions from 0 to nullptr, I squashed a lot of explicit comparisons in if statements. I left them for bool conversions in things like function arguments or returns.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>I doubt LLVM itself would opt in to such a convention immediately, nor would we probably worry enough to have a conversation to decide - we'd probably just leave the status quo. It's not really something that requires consistency or particularly harms readability.<br> </div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This came up in discussion around the check I've added to clang-tidy<br>
that simplifies boolean expressions and the question was whether or<br>
not there should be a readability check that simplifies<br>
<br>
if (p != nullptr)<br>
<br>
to<br>
<br>
if (p)<br>
<br>
and simplify<br>
<br>
if (p == nullptr)<br>
<br>
to<br>
<br>
if (!p)<br>
<br>
In the case of an if statement, I think this idiom is well established<br>
in the C/C++ community and many would find the explicit comparison to<br>
nullptr to be needlessly verbose.<br>
<br>
However, I didn't want to do something that would chafe against<br>
LLVM/clang coding conventions and I couldn't find the conventions<br>
stated explicitly anywhere.<br>
<div><div>--<br>
"The Direct3D Graphics Pipeline" free book <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_d3d-2Dpipeline&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=fQ778T9fTUvCrDcOotXMSIKL9rFJiTQ-aJR0X8b2-XI&s=YH_P4g4E2SQdmdfo7C1ibQQ_AYCLKjT8cnaulMqWGq8&e=" target="_blank">http://tinyurl.com/d3d-pipeline</a>><br>
     The Computer Graphics Museum <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__ComputerGraphicsMuseum.org&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=fQ778T9fTUvCrDcOotXMSIKL9rFJiTQ-aJR0X8b2-XI&s=tS9xPQOeCVTmIRsTKFshwyDn45Bb0yfMlg0cuxYUeXs&e=" target="_blank">http://ComputerGraphicsMuseum.org</a>><br>
         The Terminals Wiki <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__terminals.classiccmp.org&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=fQ778T9fTUvCrDcOotXMSIKL9rFJiTQ-aJR0X8b2-XI&s=VFEkdGwvD0Ixy2qz2vpqLE9C3Qg-584CW84DVa7A-5A&e=" target="_blank">http://terminals.classiccmp.org</a>><br>
  Legalize Adulthood! (my blog) <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__LegalizeAdulthood.wordpress.com&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=fQ778T9fTUvCrDcOotXMSIKL9rFJiTQ-aJR0X8b2-XI&s=q9eahUOgUeHM8D9viRQU-u4uy_z_0ZlGCmHrXnM4OxA&e=" target="_blank">http://LegalizeAdulthood.wordpress.com</a>><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">~Craig</div>
</div></div>