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

Richard legalize at xmission.com
Wed Mar 25 15:24:41 PDT 2015


In article <CAENS6EvLVQkc-_0Ajogg0QAvvEMCca8wX8N9prft891FEO37mg at mail.gmail.com>,
    David Blaikie <dblaikie at gmail.com> writes:

> On Tue, Mar 24, 2015 at 5:05 PM, Richard <legalize at xmission.com> wrote:
> > Am I missing anything?
> 
> Maybe special case chars for "return e != '\0';" ? hard to tell if it's
> chars being used as bytes or chars being used as textual characters,
> though... - and hard to tell what the common codebase convention is as to
> whether "return e;" is better than "return e != 0;" etc... - I'd be sort of
> inclined to just use the expression directly if it's valid (eg: for builtin
> types and implicit conversion operators).

When I looked this up in the standard, it has language that says it is
as if you had written 'bool(e)'.

Personally I never liked the "c != '\0'" style because '\0' is just a
more verbose way of writing 0.

> If the type's conversion operator is implicit, it might be fine to "return
> e;"

Well, for the case where it's a return value it's not as big a deal
because the implicit conversion will be done for you, but when it's a
ternary expression hidden inside another expression, then it can
subtly change the type of the expression and in that case you really
want the explicit comparison to the appropriate kind of zero or an
explicit conversion to bool.

> If the type's conversion operator is explicit, it might be more suitable to
> use static_cast<bool>.

I like the idea of checking to see if the conversion operator is
implicit or explicit.  I will incorporate that.

As to whether it should be static_cast<bool>(e) or bool(e), I was
using the latter because that's the wording in the standard.  However,
it's my understanding that the two are equivalent in the case of bool.

>There is "return !!e;" but that's lame...

Yeah, that's my least favorite and I also agree it is lame :).

> otherwise
> there's probably more explicit type-specific ways to test the object, but
> you won't be able to suggest those automatically. (eg: "return o !=
> nullptr;" for a unique_ptr, etc)

AFAIK, all the smart pointer classes have bool conversion operators.
-- 
"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>



More information about the cfe-dev mailing list