[LAD] fftw_complex and C++11

Aurélien Leblond blablack at gmail.com
Sun Jan 4 21:30:16 UTC 2015


>> Well all the plugins in ams.lv2 are coded in c++ and are compiled with the
>> c++11 standard.
>> But when ported the FFT Vocoder, it only compiles when using the c99
>> standard.

> C and C++ complex types are not compatible for C++, not even if
> they have the same binary representation as they will have for
> all modern C++ compilers.

> You can probably fix some of these errors (at least the first
> one) by including <complex.h> (not <complex>) before <fftw3.h>.

> This will make fftw use the C native complex type instead of
> its own. This will allow float to complex assignment for
> example.

> If you really want a 'pure' C++ version you will need to
> reinterpret_cast whenever you use a function that expects
> or returns a C++ complex. It won't make your code any more
> readable.

> IMHO the C++ complex type (a template class trying to hide
> its implementation) is completely useless and a real PITA,
> and a good example of the pedantic attitude that is typical
> of the C++ crowd.
> Nobody with even just a minimal knowledge of scientific
> computing would want to hide the implementation of complex
> types - almost all classical algorithms (e.g. the FFT)
> depend on it being cartesian.

What would you advise?

As far as I can see I have 2 options:
- Port the code to the c++11 standard - but you seem to think that's a bad idea
- Compile this plugin with C99 - that's the solution I have in the git
at the moment but I get the warning "cc1plus: warning: command line
option ‘-std=c99’ is valid for C/ObjC but not for C++ [enabled by
default]" and call me pedantic but I don't like warnings!

Would you know how this is handled in AMS (being c++ as well)?
I did check the code but I can't figure it out and I would like to
stay as close as possible to the actual Alsa Modular Code so it's
easier when futur modifications are applied to the code.

> A second source of problems with the vocoder is the mixing
> of floats and doubles. There is no good reason to use a
> double FFT here.

I actually did notice that, but again I don't want to "correct" it in
ams-lv2 because my aim here is to port "as-is".
I made the mistake of adapting the code when I ported the first set of
plugins but realised that was a mistake for maintenance when syncing
with changes in ams


More information about the Linux-audio-dev mailing list