Patch: bug fix for PR18218

[Marshall Clow]

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>
> 
> 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/627da54c/attachment.html>