On Mon, Nov 19, 2012 at 9:22 AM, Ed Criscuolo
<address@hidden> wrote:
I agree that changing the way gr_iir_filter takes in the taps could
be disruptive, unless backward compatibility is maintained. Some of
the group are using GnuRadio for operational systems.
Yes.
Here's two more suggestions for solutions:
1. Add an optional flag parameter to the constructor, with values
of "Old_API" and "New_API", with the default set to "Old_API".
This flag would control how gr_iif_filter interprets the taps.
It could be maintained this way for some time, with the Old_API
being deprecated, and eventually change the default to
New_API, or even make the default a cmake option.
2. Create two subclasses of filter taps that are identical in
format, and use C++ overloading to determine which constructor
or set method to use.