RE: Improve std::sort over std::array<T, N> for small values of N

[Morwenn Ed]

                                                                                                             > std::array<T, N>::iterator is just T*, so you can't really overload on it. 
> However, I can't think of any reason why such an optimization should be 
> limited to std::array. You can test in the regular std::sort if the number 
> of elements is small enough. You could use __builtin_constant_p to avoid 
> any runtime cost (and maybe test __OPTIMIZE_SIZE__ to disable your extra 
> code when size is more important than speed). But even in the main 
> std::sort, deep in the recursion, a runtime test to dispatch to a small 
> sorting network could be worth it (at least not a pessimization).
> 
>> Would you be interested in such an optimization for libstdc++?
> 
> I cannot answer that, but there were discussions of improving std::sort 
> (see the list and/or bugzilla).
> 
> -- 
> Marc Glisse

Well yeah, I realized that after I wrote the e-mail, sorry. That and the fact that
even it std::array had "proper" std::array<T, N>::iterator, it doesn't guarantee
anything about the distance between two iterators. It might be something
doable when the « range » overloads make it into the standard library though.

If I'm not mistaken, libc++ already uses a runtime dispatch with specialized
algorithms for sizes 0 to 5 so there might indeed be something to gain. I will
continue to try things in my library and come back if I have anything meaningful
to report/propose.

Thanks for taking the time to answer.

Morwenn