kfrlib / kfr

Fast, modern C++ DSP framework, FFT, Sample Rate Conversion, FIR/IIR/Biquad Filters (SSE, AVX, AVX-512, ARM NEON)
https://www.kfrlib.com
GNU General Public License v2.0
1.64k stars 252 forks source link

Fix cometa ambiguities #152

Closed xkzl closed 1 year ago

xkzl commented 2 years ago

Hello,

I have been facing some issues installing KFR on a basic Ubuntu distribution. My setup is using a scientific framework (ROOT CERN) which is compiled with Clang10, and some other parts with GCC9.

I had to update many namespace to avoid ambiguities between cometa:: and std:: methods. Here is a working update, that I compile using : mkdir build && cd build cmake -DENABLE_TESTS=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_CXX_COMPILER=clang++ -DENABLE_CAPI_BUILD=ON ../

Can somebody have a look at that ?

xkzl commented 2 years ago

https://github.com/kfrlib/kfr/issues/151

xkzl commented 2 years ago

Anybody here ? @dlevin256 ?

xkzl commented 2 years ago

I just provided an additional modification. I was using only "kfr/dft.h" header in my program and not "kfr/all.hpp", so some ambiguities were remaining.

dancazarin commented 2 years ago

Hello,

Do you run the code in Cling interpreter? It adds using namespace std implicitly before user even gets chance to include any external header. This is against c++ namespace concept and causes all these errors.

The following (bad practice) code produces the same error:

// first merge the whole std namespace into current scope
using namespace std; // Cling does this

// then including kfr headers
#include <kfr/all.hpp>
xkzl commented 2 years ago

Right that is what I am using. However, it would not be a bad thing to avoid ambiguities between namespaces I suppose.

ferdymercury commented 2 years ago

(Side note: this 'using std' might change in the future, see https://github.com/root-project/root/pull/11027)

xkzl commented 1 year ago

I just tested kfr 5.0. This is now working fine !