Woops, yeah I meant const and non const. On Dec 29, 2013 1:14 PM, "Marshall Clow" <[email protected]> wrote:
> 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]<[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
