Re: [boost] radix sort

OK, I've finished my draft implementation, although the test code (in main.cpp) is still a bit of a mess. In terms of performance, it performs poorly on 64-bit integers, competitively on 32-bit integers, and quite impressively on 16-bit and 8-bit integers. Unfortunately, I have to leave it alone for now as other things in life are pressing. If someone else wants to take it and continue it, please be my guest. I will come back and tidy things up eventually. https://github.com/jeremy-murphy/integer-sort Cheers! Jeremy On 23 July 2013 20:11, Steven Ross wrote:

On Tue, Jul 23, 2013 at 5:05 AM, Rob Stewart

...

wrote:

...

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.

I never thought of that before (using foo<int> to process something that isn't actually of int type, but acts like it, instead of foo_int as you mention). That's an interesting idea. I'm worried that it would scare off potential users, thinking that function only works on actual ints. My experience is that people usually care more about sort performance for UDTs than raw data types in operational code.

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.

Does anybody have a suggestion as to what this string trait might be? Assuming there is such a trait, should I eliminate the fallback to std::sort for unidentified types?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost