Proposing fftw_clone() to allow memory-safe C++ wrappers

[mwallerb]

One problem when using FFTW in non-trivial C++ applications is memory safety. This is particularly the case if an FFTW plan is embedded as a field in a class that should be copy-constructible and assignable:

struct X {
   X() { fftw_plan_many_dft( /* ... */ ); }
   ~X() { fftw_destroy(plan); /* freeing arrays etc. */ }
   X(const X &other) { /* what do we put here??? */ }
private:
   fftw_plan plan;
   double *in, *out;
};

As far as I can tell, there is no way to clone, i.e. to obtain a deep copy, of a plan, which is a problem in the copy constructor (and the assignment operator). An immediate workaround is to re-create the plan in the new object and copy all the data from the arrays. However, since fftw_plan is an opaque pointer, there is no portable way to recreate the plan from itself, which means the above snippet has to re-implemented for every use case.

I therefore propose to add the following function (or something similar) to the public API:

/** Return an exact deep copy (clone) of the plan, operating on new fields
 * 
 * Expects:
 *  - blueprint: original plan to be copied
 *  - new_in, new_out: the cloned plan will operate on these fields.  The data of the
 *    original plan is not copied to these fields.  The same restrictions as for 
 *    `fftw_execute_dft_*` apply.  `fftw_complex` fields should be cast to `double*`
 */
fftw_plan fftw_clone(const fftw_plan blueprint, double *new_in, double *new_out);

This would immediately allow to write a copy-constructable wrapper class around a generic fftw_plan.

If this proposal is accepted, I can help with the implementation, but I would need some pointers :)

[stevengj]

This seems reasonable to me, and should be relatively easy to implement, in principle: just create a plan for the same problem as the one stored in the plan (but with new pointers) using the WISDOM_ONLY flag.

Annoyances that immediately occur to me:

• In the guru interface you can provide separate pointers to real and imaginary parts, so you'd have to support this, probably by providing several fftw_clone functions that take arguments of different types. (Would be nice to have overloading here, oh well.)

• The problem * itself is an opaque pointer, so we would also need an internal function to clone the problem with new pointers. It is actually a pointer to one of several data structures with a "manual" implementation of a C++ like virtual method table, so you'd have to add a new "method" for cloning the problem. (Fortunately, there are only a few problem types in FFTW.)

  • You could conceivably add a similar "virtual method" for cloning plans, but there are a lot of plan types in FFTW to implement this for. That's why it seems easier to just re-create a plan with the WISDOM_ONLY flag.

• To re-create a plan, you also need to know the flags used for the original plan, but these aren't stored in the plan data structure. You'd have to add a flags field here (this would store the "internal" flags after calling mapflags, I think). Not a big deal, I guess.

  • In general we'd have to be careful about recording any kind of planner state like this, in order to ensure that the stored wisdom is applicable to the new plan being created.

[stevengj]

It would be even easier, and probably more reasonable, to just define fftw_clone(plan) that cloned it for the same array pointers. If you want to apply it to new arrays, you can just use the new-array execute functions.

(You'd still need a deep-copy method to clone the problem object, but you wouldn't have to worry about pointers to real and imaginary parts etc.)

[mwallerb]

Thanks for the info, @stevengj!
If there are no more objections, I'll probably have time on the weekend to get a first draft of this . . . As you suggested, I'll try to implement:

fftw_plan fftw_clone(const fftw_plan blueprint);

[stevengj]

(Probably it should be called fftw_copy_plan in analogy with fftw_print_plan etcetera.)

[danfortunato]

Was this ever implemented? It would be very nice!

[stevengj]

Was never implemented as far as I know. A PR would be welcome.

[stevengj]

A potential implementation is in #314.