# Custom GRC block not accepting derived class objects

**URL:** <https://www.ruby-forum.com/t/custom-grc-block-not-accepting-derived-class-objects/234307>\
**Category:** GNU Radio\
**Created:** [February 23, 2015, 11:41am UTC](https://www.ruby-forum.com/t/custom-grc-block-not-accepting-derived-class-objects/234307 "2015-02-23T11:41:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [February 23, 2015, 11:41am UTC](https://www.ruby-forum.com/t/custom-grc-block-not-accepting-derived-class-objects/234307/1 "2015-02-23T11:41:21Z")

</div>

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](http://github.com/tracierenea/gnuradio/tree/ldpc_mods)

---

<div class="post-metadata">

**Author:** ![PerezS\_Tracie\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/b5e925/32.png) [@PerezS\_Tracie\_R](https://www.ruby-forum.com/u/PerezS_Tracie_R)\
**Post date:** [February 23, 2015, 4:31pm UTC](https://www.ruby-forum.com/t/custom-grc-block-not-accepting-derived-class-objects/234307/2 "2015-02-23T16:31:46Z")

</div>

On Mon, Feb 23, 2015 at 4:06 AM, Perez, Tracie R  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> seems to be fully supported and handled by swig. Is there something else I  
> ldpc\_bit\_flip\_decoder\_impl(fec\_mtrx \*mtrx\_obj, unsigned int
> 
> 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](http://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

---

<div class="post-metadata">

**Author:** ![PerezS\_Tracie\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/b5e925/32.png) [@PerezS\_Tracie\_R](https://www.ruby-forum.com/u/PerezS_Tracie_R)\
**Post date:** [February 24, 2015, 11:20pm UTC](https://www.ruby-forum.com/t/custom-grc-block-not-accepting-derived-class-objects/234307/3 "2015-02-24T23:20:39Z")

</div>

On Feb 23, 2015, at 9:30 AM, Tom R.  
\<removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> wrote:

On Mon, Feb 23, 2015 at 4:06 AM, Perez, Tracie R  
\<removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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](http://github.com/tracierenea/gnuradio/tree/ldpc_mods)[http://github.com/tracierenea/gnuradio/tree/ldpc\_mods](http://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

Thanks very much Tom for the feedback. I spent many more hours trying to  
get swig to work directly with the child class and could never figure  
out how, or find any clues about this issue in the swig documentation.  
So as a workaround, I’ve added a get\_base\_ptr() function to the child  
classes as you described that the constellation objects do.

I updated the xml file for the decoder to call the make function as:  
self.$(id) = $(id) =  
fec.ldpc\_bit\_flip\_decoder.make(${matrix\_object}.get\_base\_ptr(),  
$max\_iterations)

Now everything is swig’ing and working great.

Thanks again,  
tracie