Patch: bug fix for PR18218

[Matt Calabrese]

Woops, yeah I meant const and non const.
On Dec 29, 2013 1:14 PM, "Marshall Clow" <mclow.lists at gmail.com> wrote:

> On Dec 29, 2013, at 9:28 AM, Matt Calabrese <rivorus at gmail.com> wrote:
>
> I didn't get a chance to look through, but another possibility to consider
> in c++03/98 as opposed to value-passing is to make overloads that are the
> combinations of both l-value and r-value references for the parameters in
> question.
>
> I’m confused.
> In general, we don’t have rvalue references in C++98/03.
> Did you man const/non-const references?
>
> — Marshall
>
> This would be closer to what the standard seems to specify as it doesn't
> have those copies. It would be somewhat annoying since it implies 2^n
> overloads per function, but since n is only ever 1, 2, or 3, it should be
> tractable. Then again, I'm not sure how many overloads would be "too many"
> to introduce here.
> On Dec 29, 2013 11:55 AM, "Marshall Clow" <mclow.lists at gmail.com> wrote:
>
>> 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<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/2aabc089/attachment.html>