Re: [boost] Proposal for Linear sort library

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-06-03 19:43:48

On Sun, Jun 02, 2002 at 10:21:27PM -0500, Jeremy Siek wrote:
> One thought about the interface. The counting_sort_type class is for a
> kind of concept checking? Is there a way we could do checking without
> the BOOST_DECLARE_COUNTING_SORT_TYPE macro?

Good point, actually, two answers: the first is that the whole library
needs tightening in terms of concepts and checking. For instance, I need
to make sure that the value type of the iterator is convertible to the
key type of the property. Internally, I don't even check the counting
sort type, but I should. Also, the real point of having counting sort
types is when using the (yet unwritten) boost::sort which should check
the type, the size of the range, and a few other things, and decide
which algorithm is best to use. As I said, it still has to be done.

The second is that the BOOST_DECLARE_COUNTING_SORT_TYPE uses class
specialization, and the purpose of the macro is to provide support for
compilers who do not support specialization. It's also to save the
typing (internally, but if I need it internally, then why not export it
to the user as well?)

I'd like the library to work on all platforms (because it's so
fundamental).  Now maybe all compilers support (full) specialization by
now. So this may just be for the convenience. But I agree the macros get
ugly when going to BOOST_DECLARE_RADIX_SORT_TEMPLATE_...

Let's think and talk about it some more. I accept any reasonable
interface as long as it is safe, and it's transparent to the user, and
there can be some kind of dispatch for boost::linear_sort.
Cheers,
-- 
Hervé