Re: Adding my sorting algorithm, ska_sort, to boost, attempt 2

From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2020-01-29 06:54:17

On Thu, 23 Jan 2020 at 18:34, Malte Skarupke via Boost
<boost_at_[hidden]> wrote:
>
> > If I understood correctly, your new algorithm increases the requirement
> > for Boost.Sort to C++17 from C++11. I don't see a good reason for doing
> > that. You can replace if constexpr and the generic lambdas in your
> > implementation with other code constructs that work on C++11.
>
> It only requires C++17 if you want to use ska_sort. The other algorithms remain at C++11. I agree that this is a little unfortunate, but when I briefly tried to get rid of "if constexpr" in the code, it turned out to be a giant pain. It would also probably make the code compile much more slowly. If you are trying to sort nested types, like vector<vector<pair<string, int>>>, compile time can explode without some of the short circuiting that I'm doing using if constexpr. (I can explain why it explodes if you're interested, but for now I'll just say that it works different from comparison based sorting and you have to instantiate new code at every level of depth) I know I can do the same short circuiting without if constexpr if I put in enough work, but I think the code quality would suffer a lot, making the code much harder to read and maintain. (not that it's simple as is, but it would go from "hard to read" to "impossible to read")

My experience with looking at C++17 codebases (which are still quite
limited) suggests that generalized use of "if constexpr" is a code
smell that suggests bad design, making code difficult to maintain and
extend and also causing unnecessarily long compilation times.

Designing generic components and combining them in a more traditional
fashion leads to more sharing of template instantiations as
special-casing happen at the declaration boundary rather than in the
middle of a definition.
If constexpr also encourages placing local specializations at random
points in the generic code instead of looking at the big picture,
rationalizing requirements and deferring any special action to a
policy that models a more or less refined concept, which definition is
in a single place within the code. Local changes will eventually pile
up, and since they probably have some relation to each other but are
not together in the code, they end up being fragile.

I haven't looked at your code in particular, but that might be
something to consider.