Subject: Re: [boost] radix sort
From: Jeremy Murphy (jeremy.william.murphy_at_[hidden])
Date: 2013-07-23 11:19:49
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
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.
On 23 July 2013 20:11, Steven Ross <spreadsort_at_[hidden]> wrote:
> On Tue, Jul 23, 2013 at 5:05 AM, Rob Stewart <robertstewart_at_[hidden]
> > 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
> > 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
> 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk