Re: [boost] radix sort

On Jul 23, 2013, at 6:11 AM, 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.

Perhaps it is, but that's not what I was saying. I was referring to foo<int> vs. foo<float>, for example, both having the name "foo".

I'm worried that it would scare off potential users, thinking that function only works on actual ints.

I was under the impression that your int function only worked on ints. That's the point of foo<int>.

My experience is that people usually care more about sort performance for UDTs than raw data types in operational code.

In that case, you need to figure out how to permit users to adapt their UDT to your function. Traits and the Bridge Pattern come to mind.

...

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?

It all depends upon your algorithm. The simplest scheme is to adapt all types the same way. You provide the specializations for the supported built-in types, with no primary specialization. Users specialize it for their UDT and they're off. There are other approaches possible, too.

Assuming there is such a trait, should I eliminate the fallback to std::sort for unidentified types?

You could keep that fallback, but one presumes choosing your algorithm was a conscious choice over std::sort(), so not providing a fallback seems better. ___ Rob (Sent from my portable computation engine)