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. Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
