What Bjarne doesn't mention is the enormous difference in code size between qsort and std::sort. The flexibility of having the compiler generate a sorting routine from std::sort is convenient but enormously redundant in many cases. In LLVM, we have array_pod_sort which is just a thin wrapper around qsort in order to avoid the code bloat of std::sort:
http://llvm.org/docs/doxygen/html/namespacellvm.html#ae5788f...For example, the following generates about 2KB of instructions (and will for basically every new type you want to sort):
#include
struct SomeStruct {
int X;
};
void foo(SomeStruct *SS, int NSS) {
std::sort(SS, SS + NSS, [](SomeStruct LHS, SomeStruct RHS) {
return LHS.X > RHS.X;
});
}
A qsort equivalent will only emit code for the comparator which is just a handful of instructions.
C++ templates may be type safe and all, but at the end of the day they spew duplicated code just as much as those header-only macro-based C containers and algorithms; really more because it's less painful to write templates (vs. macros) and so you do it more, and there is more stuff in the templates. So even though in general the specialized generated code might be faster in most cases (as Bjarne likes to tout), the overall hit on your code size (and i-cache) can be dreadful. Currently, avoiding this issue in C++ just requires diligence on the part of the coder (some optimizations like LLVM's mergefunc can help, but in general it is a pretty hard problem and compilers are not Sufficiently Smart (TM) yet).