[cfe-dev] discriminating explicit boolean expressions from implicit boolean expressions in the AST

[David Blaikie]

On Thu, Mar 26, 2015 at 12:04 PM, Richard <legalize at xmission.com> wrote:

>
> In article <E1YbBnb-00023F-6K at shell.xmission.com>,
>     Richard <legalize at xmission.com> writes:
>
> > I think this is where the wording in the standard allows you to write:
> >
> > if (sp) { ... } else { ... }
> >
> > without having to write an explicit conversion to bool.  I didn't look
> > up the language of how the ternary expression interprets the
> > conditional expression.  I will do that and see what it says.
>
> As I read the standard, the same interpretation is applied to
> conditions of if statements as is applied to the condition in a
> ternary operator:
>
> 4. [conv]
>
>     "Certain language constructs require that an expression be converted
>     to a Boolean value.  An expression e appearing in such a context is
>     said to be contextually converted to bool and is well-formed if and
>     only if the declaration bool t(e); is well-formed, for some invented
>     temporary variable t (8.5)."
>
> 5.16 [expr.cond]
>
>     "The first expression is contextually converted to bool (Clause 4)."
>
> 6.4 [stmt.select]
>
>     "The value of a condition that is an initialized declaration in
>     a statement other than a switch statement is the value of the
>     declared variable contextually converted to bool (Clause 4)."
>
> So I would be in step with the standard if I replaced all expressions
> e with bool(e), but I'd like to avoid the unnecessary conversion where
> possible.
>

Right - sorry, the issue I'm trying to address isn't that bool(e) isn't
valid for all the cases where you're doing this conversion (it is) but it's
also valid for a bunch of other cases & that can make code harder to read -
it's the usual reason for using C++ style casts (that can only do a few
specific things each) rather than the C style cast which can do many
things, sometimes not what you want. Yes, in this case, it'd do the same
thing, but when the developer comes back to read the code next
week/year/etc or refactors the code (changing the type of the variable),
using the least powerful, most legible, mechanism will help them avoid some
potential traps.

Does that make sense?

- David


> --
> "The Direct3D Graphics Pipeline" free book <
> http://tinyurl.com/d3d-pipeline>
>      The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
>          The Terminals Wiki <http://terminals.classiccmp.org>
>   Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150327/372e84f3/attachment.html>