Patch: bug fix for PR18218

[Matt Calabrese]

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. 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/18c4c1c6/attachment.html>