On Fri, May 2, 2014 at 9:40 AM, Philip Reames <[email protected]> wrote: > > On 05/02/2014 02:18 AM, David Chisnall wrote: >> >> On 2 May 2014, at 09:16, David Tweed <[email protected]> wrote: >> >>> I wonder if, with C++11 named initialization syntax for PODs, something >>> could be done so that in cases like this a (function specific, I guess) >>> "optional options object" could be used. (This would avoid one of the big >>> problems with C++ optional arguments, which is that if one towards the >>> end >>> needs to be set to a non-default value all the preceding options need >>> setting.) That would certainly make things a lot easier to read in cases >>> like these. >> >> The related issue is that they complicate overloading. I've been bitten a >> few times in clang code by the compiler deciding that, when I specified a >> pointer instead of a reference for a parameter, it would happily coerce it >> to a bool and then use the default values for the rest of the parameters, >> giving some very strange results - no errors, no warnings, just the code >> doing something unexpected. >> >> David >> > David, I think you're pointing out a slightly different issue... one I've > also been bitten by. > > Does anyone know of a legitimate reason to have an implicit conversion to > bool as a function argument? Maybe we should add an optional warning for > this case in particular?
My suspicion is that this would (just barely) not meet our bar for false positive rate. (my bet, though it's not a sure thing, is that we do this in the LLVM project at least tens of times intentionally (ie: not a bug, but subtle code)) But, arguably, rewriting the argument from "func(x)" to "func(x != nullptr)" is a benefit in readability and sometimes we're OK with a few more false positives if they're just "badly written/confusing code" - David _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
