On Jul 22, 2013, at 6:33 AM, Steven Ross
Use a function template, don't implement the primary specialization. Just implement the specializations you support. If you dispatch to a static member function of a class template, PTS with type traits can give wider support without specializing for otherwise similar types. (all integral types, for example).
Won't the user have to give their class a trait to use the function, if it isn't a raw integer type? The other concern is that the integer and string algorithms are different in terms of worst-case performance, as the string algorithm has to deal with variable-length inputs.
You're over-thinking this. I wasn't referring to UDTs. foo_int and foo<int> are different ways to spell a function targeting int. The latter happens to allow for use of the same identifier as the name, for different types, though it must be specialized. Specializing is most convenient when argument type deduction does the work, but then overloading may do the same for non-templated functions, depending on the arguments.
Currently there is a spread_sort wrapper that selects integers or floats using PTS, and failing that, defaults to std::sort. I've yet to see a way to identify that a data type is string-like. I can remove the fallback if that's the desired behavior (to avoid confusing the user about which algorithm is in use), but that doesn't resolve the string issue.
If you want to offer string behavior for UDTs, you can combine PTS, for known string types, with a fallback to a trait that indicates/bridges string behavior. ___ Rob (Sent from my portable computation engine)