ODR failure due to missing `inline` for vectorization-related functions

[LTLA]

Title says it all. If hnswlib is included in multiple source files, we observe linking errors like:

CMakeFiles/libtest.dir/src/find_nearest_neighbors.cpp.o: In function `cpuid(int*, int, int)':
/home/luna/Code/knncolle/build/_deps/hnswlib-src/./hnswlib/hnswlib.h:29: multiple definition of `cpuid(int*, int, int)'
CMakeFiles/libtest.dir/src/Hnsw.cpp.o:/home/luna/Code/knncolle/build/_deps/hnswlib-src/./hnswlib/hnswlib.h:29: first defined here
CMakeFiles/libtest.dir/src/find_nearest_neighbors.cpp.o: In function `xgetbv(unsigned int)':
/home/luna/Code/knncolle/build/_deps/hnswlib-src/./hnswlib/hnswlib.h:32: multiple definition of `xgetbv(unsigned int)'
CMakeFiles/libtest.dir/src/Hnsw.cpp.o:/home/luna/Code/knncolle/build/_deps/hnswlib-src/./hnswlib/hnswlib.h:32: first defined here
CMakeFiles/libtest.dir/src/find_nearest_neighbors.cpp.o: In function `AVXCapable()':
/home/luna/Code/knncolle/build/_deps/hnswlib-src/./hnswlib/hnswlib.h:54: multiple definition of `AVXCapable()'
CMakeFiles/libtest.dir/src/Hnsw.cpp.o:/home/luna/Code/knncolle/build/_deps/hnswlib-src/./hnswlib/hnswlib.h:54: first defined here
CMakeFiles/libtest.dir/src/find_nearest_neighbors.cpp.o: In function `AVX512Capable()':
/home/luna/Code/knncolle/build/_deps/hnswlib-src/./hnswlib/hnswlib.h:81: multiple definition of `AVX512Capable()'

etc.

I believe this should be easily fixed by adding an inline at the start of every function's definition, e.g.

inline void cpu_x86::cpuid(int32_t out[4], int32_t eax, int32_t ecx) {
    __cpuidex(out, eax, ecx);
}

This includes all the DISTFUNC-based functions in the space_*.h headers.

[yurymalkov]

Hi @LTLA,
This has fixed in #383 , right? I guess we can make a release for that.

[LTLA]

Oh, great. I only ever pull from your master in my builds, so I didn't see that. Would be great to get #383 in there.

Interesting that the PR uses static to resolve ODR issues, as opposed to inline. I'd speculate that inline would yield smaller binaries because static forces each translation unit to have its own local copy of the function. But I don't really know. Probably doesn't matter.

[yurymalkov]

I see. Thanks for noting! Probably inline would be a better fit.