On March 16, Lewis Hyatt wrote I took a look at it. Some of my thoughts: -You should provide random access iterator interfaces, not just a bare pointer. -Your docs say you require T to be an integral type or have operator< defined, I think you meant to say "built-in arithmetic type" or something similar. You should also let the user provide their own comparison functor instead of requiring them to overload operator< -Based on your descriptions, it looks like merge_sort is the same as std::stable_sort and quicksort is the same as std::sort, more or less. (Except the standard functions have more generic interfaces). What advantage are they supposed to have over the standard functions? I tried some timings, and found that for both ints and doubles, on my system, your quicksort is about 50% slower than std::sort, and your mergesort is about 5% faster than std::stable_sort, at least for the case of already-sorted data. -It might make more sense to focus on radix sort, since that is not already offered in the standard library... Are you sure about the quicksort speed difference? That seems like a huge difference. Did you have inlining enabled? Also, the current versions are not the final forms. I am implementing random-access iterators and user-provided functions.