<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Dec 29, 2013, at 9:28 AM, Matt Calabrese <<a href="mailto:rivorus@gmail.com">rivorus@gmail.com</a>> wrote:<br><div><blockquote type="cite"><p dir="ltr">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. </p></blockquote><div>I’m confused.</div><div>In general, we don’t have rvalue references in C++98/03.</div><div>Did you man const/non-const references?</div><div><br></div><div>— Marshall</div><div><br></div><blockquote type="cite"><p dir="ltr">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.</p>
<div class="gmail_quote">On Dec 29, 2013 11:55 AM, "Marshall Clow" <<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">On Dec 27, 2013, at 3:21 PM, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>> wrote:<br><div><br><blockquote type="cite"><br>On Dec 19, 2013, at 3:38 PM, Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</a>> wrote:<br>
<br><blockquote type="cite">On Dec 19, 2013, at 6:36 PM, Matt Calabrese <<a href="mailto:rivorus@gmail.com" target="_blank">rivorus@gmail.com</a>> wrote:<br><br><blockquote type="cite">Ah, I'm out of my domain, I didn't realize the wording of [c.math] 11<br>
in addition to [global.functions] was what was causing the need for<br>the templates... I think I'm starting to understand the full issues<br>here. One solution might be something along these lines:<br><br>1) Declare the overloads that are explicitly specified. These are just<br>
3 overloads total for each IIUC.<br>2) Declare a template overload that takes r-value references for each<br>argument that is enabled if and only if the corresponding function<br>would be callable with the forwarded arguments (this can be done with<br>
a metafunction implemented via SFINAE). This function would internally<br>cast the arguments to the corresponding type and invoke the actual<br>function (therefore it exhibits the same observable behavior as if<br>this template didn't exist).<br>
3) Declare a second template overload that takes r-value references<br>for each argument but that is DISABLED if the corresponding function<br>would be callable with the forwarded arguments. This overload would be<br>the one that does something along the lines of the trick that was<br>
originally implemented (though adjusted for r-value refs). It would do<br>an is_arithmetic check rather than the __numeric_type trick.<br><br>The overall result would be that anything that would have been<br>callable with only the original overloads would still work and have<br>
the same behavior. The enable_if makes sure that the fallback would be<br>used only in the cases where such a call would have failed with only<br>the explicitly specified overloads. I think this satisfies all of the<br>standard's requirements.<br>
</blockquote><br><nod> I've been thinking the same thing since your first reply. Thanks for bringing this issue up.<br></blockquote></blockquote></div><br><div>Here’s a patch for review.</div><div>It only deals with “pow”, but the same techniques work on all the other calls.</div>
<div><br></div><div>[ I chose “pow” because there’s a “pow” in <complex>, and we have to not step on that. ]</div><div><br></div><div>Anyway - if we have rvalue references, then we’ll use them. If not, then we pass by value.</div>
<div>We can’t pass by const &, because the conversion operator might not be const.</div><div>We can’t pass by non-const &, because that would fail on literal values.</div><div><br></div><div>The exception specification depends on conversion to floating point.</div>
<div>Note that pow (double, double) is NOT noexcept - because that’s defined elsewhere :-(, and we can’t change that.</div><div>[ Even though it will never throw, we can’t mark it as noexcept ]</div><div><br></div><div>noexcept is QOI - it’s not specified in the standard.</div>
<div><br></div><div><span>-- Marshall</span></div><div><span style="border-collapse:separate;border-spacing:0px"><br>Marshall Clow Idio Software <<a href="mailto:mclow.lists@gmail.com" target="_blank">mailto:mclow.lists@gmail.com</a>><br>
<br>A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).<br> -- Yu Suzuki</span></div><div><span style="border-collapse:separate;border-spacing:0px"><br>
</span></div></div><br><div style="word-wrap:break-word"></div><br></blockquote></div>
</blockquote></div><br></body></html>