# Specify which methods show up in SWIG version of C++ block

**URL:** <https://www.ruby-forum.com/t/specify-which-methods-show-up-in-swig-version-of-c-block/246382>\
**Category:** GNU Radio\
**Created:** [October 9, 2013, 10:38pm UTC](https://www.ruby-forum.com/t/specify-which-methods-show-up-in-swig-version-of-c-block/246382 "2013-10-09T22:38:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\
**Post date:** [October 9, 2013, 10:38pm UTC](https://www.ruby-forum.com/t/specify-which-methods-show-up-in-swig-version-of-c-block/246382/1 "2013-10-09T22:38:14Z")

</div>

I’m working on some custom C++ blocks. I would like to have a few  
methods in the C++ world visible to Python so that they can be called  
directly. My understanding is that GRC can then make such things  
visible through the tag in the block’s XML specification.

Looking at the GR3.7 version of fir\_filter, for instance, shows that  
it has a “set\_taps” method and an “update\_tap” method, both of which  
are public. However, only “set\_taps” gets translated into the SWIG  
Python version of the fir\_filter block, while “update\_tap” does not.  
What part of the gr-filter source tree instructs SWIG to include one  
but not the other? Does it have something to do with the way the  
GR\_SWIG\_BLOCK\_MAGIC2() macro works within filter\_swig.i?

Short version: how do I instruct the SWIG build process to translate a  
particular method of a C++ GR block into its Python version?

Thanks in advance.

Ethan

---

<div class="post-metadata">

**Author:** ![Ethan\_Trewhitt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@Ethan\_Trewhitt](https://www.ruby-forum.com/u/Ethan_Trewhitt)\
**Post date:** [October 9, 2013, 11:23pm UTC](https://www.ruby-forum.com/t/specify-which-methods-show-up-in-swig-version-of-c-block/246382/2 "2013-10-09T23:23:14Z")

</div>

When you create a block with gr\_modtool your implementation goes in the  
lib/[block\_name]\_impl.[h|cc] files. However, the swig procedures look at  
the include/[package\_name]/[block\_name].h files to determine which  
methods  
to expose in the generated python class. So, to make a C++ method  
available  
in the python class, create a virtual method in the  
include/[package\_name]/[block\_name].h and implement it in the  
lib/[block\_name]\_impl.[cc|h] subclass.

---

<div class="post-metadata">

**Author:** ![Ethan\_Trewhitt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ecb155/32.png) [@Ethan\_Trewhitt](https://www.ruby-forum.com/u/Ethan_Trewhitt)\
**Post date:** [October 9, 2013, 10:56pm UTC](https://www.ruby-forum.com/t/specify-which-methods-show-up-in-swig-version-of-c-block/246382/3 "2013-10-09T22:56:57Z")

</div>

Declare a pure virtual function in (for example)  
gr-OOT/include/OOT/myblock.h :

virtual int how\_many\_things(const int n) const = 0;

Then declare a concrete function in gr-OOT/lib/myblock\_impl.h :

int how\_many\_things(const int n) const;

Then define your concrete function in gr-OOT/lib/myblock\_impl.cc :

int how\_many\_things(const int n)  
{  
return n;  
}

If you added your block with gr\_modtool, you’ll find this in  
gr-OOT/swig/OOT\_swig.i :

%{  
…  
#include “OOT/myblock.h”  
…  
%}  
…  
%include “OOT/myblock.h”  
…  
GR\_SWIG\_BLOCK\_MAGIC2(OOT, myblock);

The above statements will automagically SWIG anything defined in  
myblock.h.