Ability to pass container types other than complex_vector<T> for FFT computation

Hi,

First of all I wanted to appreciate this repo. I started creating my own FFT library until I realized I wanted to used fixed-point representation, and CNL led me to here. I am currently trying to adapt it to be used for embedded systems and I hit a wall. Apologies in advance if I missed something as I explain the issue and potential solution.

For embedded systems one would typically want to have all the possible allocation of an application in the stack, and knowing the nature of the signal to have the spectrum calculated from, it is possible to set the size of the FFT buffer from the get-go and avoid storing it dynamically, as complex_vector does. One possibility is using the Embedded Template Library (https://www.etlcpp.com/) and its container type, etl::vector.

My investigations, so far, led me to the conclusion that, if one wants to adapt the CDSP code with minimal effort to support ETL (or other types of containers, for that matter), it would be nice that the operator[] from complex_vector returns a reference to the indexed complex number. Since real and imaginary parts are stored in different containers, that gets tricky. To modify the data from the vectors, one needs to use set_at() which is not supported by the ETL and other container types.

Hence, I wanted to ask you what would be the pitfalls of storing the complex data in a vector of std::pairs instead of separate vectors. This way the operator[] overload could be used to get a reference to the respective pair. This way, the change in fft.hpp would revolve around updating the template arguments.

hbe72 / cdsp

Ability to pass container types other than complex_vector<T> for FFT computation #18