Patch: bug fix for PR18218

Marshall Clow mclow.lists at gmail.com
Sun Dec 29 08:53:07 PST 2013


On Dec 27, 2013, at 3:21 PM, Marshall Clow <mclow.lists at gmail.com> wrote:

> 
> On Dec 19, 2013, at 3:38 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> 
>> On Dec 19, 2013, at 6:36 PM, Matt Calabrese <rivorus at gmail.com> wrote:
>> 
>>> Ah, I'm out of my domain, I didn't realize the wording of [c.math] 11
>>> in addition to [global.functions] was what was causing the need for
>>> the templates... I think I'm starting to understand the full issues
>>> here. One solution might be something along these lines:
>>> 
>>> 1) Declare the overloads that are explicitly specified. These are just
>>> 3 overloads total for each IIUC.
>>> 2) Declare a template overload that takes r-value references for each
>>> argument that is enabled if and only if the corresponding function
>>> would be callable with the forwarded arguments (this can be done with
>>> a metafunction implemented via SFINAE). This function would internally
>>> cast the arguments to the corresponding type and invoke the actual
>>> function (therefore it exhibits the same observable behavior as if
>>> this template didn't exist).
>>> 3) Declare a second template overload that takes r-value references
>>> for each argument but that is DISABLED if the corresponding function
>>> would be callable with the forwarded arguments. This overload would be
>>> the one that does something along the lines of the trick that was
>>> originally implemented (though adjusted for r-value refs). It would do
>>> an is_arithmetic check rather than the __numeric_type trick.
>>> 
>>> The overall result would be that anything that would have been
>>> callable with only the original overloads would still work and have
>>> the same behavior. The enable_if makes sure that the fallback would be
>>> used only in the cases where such a call would have failed with only
>>> the explicitly specified overloads. I think this satisfies all of the
>>> standard's requirements.
>> 
>> <nod> I've been thinking the same thing since your first reply.  Thanks for bringing this issue up.

Here’s a patch for review.
It only deals with “pow”, but the same techniques work on all the other calls.

[ I chose “pow” because there’s a “pow” in <complex>, and we have to not step on that. ]

Anyway - if we have rvalue references, then we’ll use them. If not, then we pass by value.
We can’t pass by const &, because the conversion operator might not be const.
We can’t pass by non-const &, because that would fail on literal values.

The exception specification depends on conversion to floating point.
Note that pow (double, double) is NOT noexcept - because that’s defined elsewhere :-(, and we can’t change that.
[ Even though it will never throw, we can’t mark it as noexcept ]

noexcept is QOI - it’s not specified in the standard.

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists at gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131229/2bb50216/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: isnan2.patch
Type: application/octet-stream
Size: 4439 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131229/2bb50216/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131229/2bb50216/attachment-0001.html>


More information about the cfe-commits mailing list