Re: [Discuss-gnuradio] Custom GRC block not accepting derived class objects

[Tom Rondeau]

On Mon, Feb 23, 2015 at 4:06 AM, Perez, Tracie R <address@hidden> wrote:

I'm hoping for suggestions from the GRC and swig savvy folks on the list.

I am trying to add LDPC functionality to gr-fec [1]. I made a GRC block for a decoder class. The decoder class constructor accepts a base class called fec_mtrx. In GRC, I am trying to give the decoder block an input of an object of a class derived from fec_mtrx, called ldpc_R_U_mtrx. The issue is that swig is giving an error that it expects the base class as the argument.

>From the swig documentation, this type of inheritance and type checking seems to be fully supported and handled by swig. Is there something else I need to consider in either the block's cheetah template for the make call, or the swig files?

The organization of the classes is like:

class FEC_API ldpc_R_U_mtrx : public fec_mtrx  {    };

class FEC_API ldpc_bit_flip_decoder_impl : public ldpc_bit_flip_decoder
{
public:
    ldpc_bit_flip_decoder_impl(fec_mtrx *mtrx_obj, unsigned int max_iter=100);
}

And then in variable_ldpc_bit_flip_decoder.xml I've got: self.$(id) = $(id) = fec.ldpc_bit_flip_decoder.make($matrix_object, $max_iterations)

In my flowgraph, I provide the decoder block an input of a ldpc_R_U_mtrx variable, and swig throws:
TypeError: in method 'ldpc_bit_flip_decoder_make', argument 1 of type 'gr::fec::code::fec_mtrx *

So to me, it seems like swig is not recognizing that the ldpc_R_U_mtrx class derives from fec_mtrx. Not sure what to do about that except to try and “un-inherit" the classes and overload the decoder constructor...

Thanks for any tips,
tracie


[1] github.com/tracierenea/gnuradio/tree/ldpc_mods

Hey Tracie,

Unfortunately, I don't have a good, easy answer for you. It does seem like this should work fine. I'm trying to think of examples where we've done this before. The closest that I know of is with the constellation objects and something like the constellation_receiver that takes in just the base class. All of the function calls required are implemented in that base class, but overloaded by the child class. It also has a function ".base()" that returns the pointer to the child object as the base class so we can pass it through.

Figuring out how to get swig to work with the child class would probably be the better solution, but maybe you can use the constellation class model to get things going.

Tom