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

[David Blaikie]

On Wed, Mar 25, 2015 at 3:24 PM, Richard <legalize at xmission.com> wrote:

>
> 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.
>

They do, but they're explicit and my point was "return bool(sp);" is less
good than "return sp != nullptr;" - so without knowing the domain-specific
bool test it's probably hard to pick/suggest the best fix.

(std::experimental::optional is different, for example, it's comparable to
"nullopt" not nullptr)


> --
> "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/20150325/47224a51/attachment.html>