static pointers require at least optimization level 2 in order to be inlined, it's better to use lambda or just pass meta-type as template arg holds operator () contains the scalar operation. for example:

template<typename Tag>
struct cmp_lt {
    template <typename T>
    bool operator () (T a, T b)
    { return a < b; }
};

template<>
struct cmp_lt<half_tag> {
    bool operator () (npy_half a, npy_half b)
    { return HALF_LT(a, b); }
};
// specialize the rest float/cfloat
// ...

to pass it

argbinsearch_<half_tag, cmp_lt>(...);

to initialize it

template<class Tag, template<typename> class Cmp, class T = typename Tag::type>
static int argbinsearch_(...)
{
    Cmp<Tag> cmp;
}

edit: fix template arg

This is actually very compiler specific, see https://godbolt.org/z/7TGKvM8o3
I've yet to see a case where -O1 is used in a place where optimization really matters, so I'm not a big fan of this argument. at -O2 all compiler inline the function pointer correctly, and I tend to prefer readability over optimizing for -O1. What are the thoughts of the other reviewers on that point?

I can see -O1 being used for debugging. -O3 breaks occsionally, but -O2 usually fixes it. That said, having unstated assumptions floating around could be dangerous. Is it the case that inlining is not required for the code to run correctly? If so, might add a comment

It doesn't change the smeantic of the code, it only changes inlining, i.e. execution speed.

This is actually very compiler specific, see https://godbolt.org/z/7TGKvM8o3

on GCC -O1 https://godbolt.org/z/4b6f3hxcM isn't going to inline static pointers.

I tend to prefer readability over optimizing

passing a function pointer for internal use that can be handled in compile time is 100% against readability, 100% against the idea behind the existence of C++. The above suggestion is a common pattern we tend to use it since C++ 98 and it can be replaced with lambda.

@charris,

I can see -O1 being used for debugging

we use -O0 for debugging, distros may build NumPy with -O1.

It doesn't change the smeantic of the code, it only changes inlining, i.e. execution speed.

giving a chance for the compiler to avoid inlining a function with one line expression that can be executed within a loop is in general a sign of bad design.

I thought BOOL_LT was used else where, which is why I reused existing symbol: to prevent duplication. it turns out it's not the case, so I'll move the definition to the tags.

It's actually used in heap sort. To avoid duplication, I'll keep the current implementation until it's not needed elsewhere. Small steps!

adding extern C to npysort_common.h will fix the duplication between C and C++ symbols without the need of wraps around via static pointers.

Nice !, would you please sort out the code style here?