On Dec 29, 2013, at 9:28 AM, Matt Calabrese <[email protected]> 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" <[email protected]> wrote: > On Dec 27, 2013, at 3:21 PM, Marshall Clow <[email protected]> wrote: > >> >> On Dec 19, 2013, at 3:38 PM, Howard Hinnant <[email protected]> wrote: >> >>> On Dec 19, 2013, at 6:36 PM, Matt Calabrese <[email protected]> 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:[email protected]> > > A.D. 1517: Martin Luther nails his 95 Theses to the church door and is > promptly moderated down to (-1, Flamebait). > -- Yu Suzuki > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
