# Why SWIG has been selected as C++ wrapper for Python for GNURadio?

**URL:** <https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496>\
**Category:** GNU Radio\
**Created:** [June 20, 2014, 10:35am UTC](https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496 "2014-06-20T10:35:12Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\
**Post date:** [June 20, 2014, 10:35am UTC](https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496/1 "2014-06-20T10:35:12Z")

</div>

Hi All

This is a question intended for the Software designers and maintainers  
of  
the GNURadio

Is there a specific reason / advantage of using SWIG as a C++ wrapper  
over  
using other avaialble wrappers for C++ as Boost.Python , Cython etc  
…  
in the context of GNURadio ?

Thanks!  
Joe

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 20, 2014, 11:23am UTC](https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496/2 "2014-06-20T11:23:53Z")

</div>

On 06/20/2014 10:34 AM, Joe D wrote:

> This is a question intended for the Software designers and maintainers  
> of the GNURadio
> 
> Is there a specific reason / advantage of using SWIG as a C++ wrapper  
> over using other avaialble wrappers for C++ as Boost.Python , Cython  
> etc … in the context of GNURadio ?

First, you need to realize that the decision to use SWIG was made a long  
way back, when there were less alternatives. At the time, one important  
argument was that Python wasn’t the only scripting language that was to  
be supported.  
At this point, we know a lot of SWIG’s quirks, and there is little  
reason to change. It does all we need (although it could do somethings a  
bit faster, the build times are still annoying), and it integrates well  
with our code structure.  
To be honest: Few of us are 100% happy with SWIG, but it’s the devil we  
know 🙂

However, while there are alternatives to SWIG worth considering, Cython  
is not suitable for what we need. I haven’t looked into Boost.Python  
closely, though.

M

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 20, 2014, 11:44am UTC](https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496/3 "2014-06-20T11:44:05Z")

</div>

Hi Joe,

Disclaimer: I haven’t been around when SWIG was introduced into GNU  
Radio. These are somewhat educated guesses, but since I’ve had _some_  
fun with SWIG, I wondered myself and this is what I rationalized.

- SWIG was around at the time GNU Radio was rewritten, which must have  
been around 2004. I think the choice to use SWIG was made before that  
[1]. SWIG has been around since '96, so I guess it was expected to be  
somewhat stable/reliable. Boost.Python was started in '03, and if the  
guys behind it decided that they had to conceptually rework something,  
the second year it exists sounds like a dangerous time to use it. ctypes  
is (I think) python-2.5esque, so this couldn’t have been around back in  
the day, and only does basic C wrapping.
- It does what GNU Radio needed: Generate python wrapper classes without  
the developers needing to actually write code; defining the interface  
was enough for a “normal” block to be SWIG’ed, and specialized wrapper  
classes only had to be written for some of the core things so that  
things like connect()ing blocks would work. It is arguable if writing  
and maintaining the SWIG .i files (especially since we’re talking about  
the autohell era) was worth the trouble of avoiding that, but for the  
only comparable competitor Boost.Python, you had to define wrapper  
classes, and references to the classes wrapped and their members.  
Pyrex/Cython now is a complete different language and would have made  
GNU Radio something much more multi-paradigmatic, whilst adding even  
more to the “active” codebase that had to be maintained by hand.
- It was expected that if SWIG wasdone right, GNU Radio could end up  
with multiple scripting language interfaces [2]. Nowadays, people are  
content to use python, especially since we now (feels like yesterday)  
have support to write gr::block classes in python, which of course  
needed a lot of gateway work, so (to my knowledge) there haven’t been  
efforts to make use of more than the C++ and Python SWIG  
capabilities[3].

Greetings,  
Marcus

[1]  
[http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=SWIG&submit=Search!&idxname=discuss-gnuradio&max=20&result=normal&sort=date%3Aearly](http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=SWIG&submit=Search!&idxname=discuss-gnuradio&max=20&result=normal&sort=date%3Aearly)  
[2]  
[http://lists.gnu.org/archive/html/discuss-gnuradio/2003-03/msg00135.html](http://lists.gnu.org/archive/html/discuss-gnuradio/2003-03/msg00135.html)  
[3] After all, for scripting python works really nice and is easy to  
learn. If you wanted to use a fast Matrix operation in Fortran, there is  
no stopping you from doing that from C++, which is the programming  
language of choice for performance-critical blocks, anyway, as long as  
your Fortran and C++ compilers are ABI-compliant. If you wanted

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 20, 2014, 7:24pm UTC](https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496/4 "2014-06-20T19:24:27Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 20, 2014, 4:25pm UTC](https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496/5 "2014-06-20T16:25:41Z")

</div>

On Fri, Jun 20, 2014 at 5:42 AM, Marcus Müller  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> decided that they had to conceptually rework something, the second year it  
> competitor Boost.Python, you had to define wrapper classes, and references
> 
> choice for performance-critical blocks, anyway, as long as your Fortran and  
> in the context of GNURadio ?
> 
> Thanks!  
> Joe

Martin and Marcus nicely answered the question for you.

Just wanted to say that while we’re not entirely impressed with some  
features of SWIG, the fact that it’s working well for us and the  
disruption  
we would cause switching it out is not worth it. We’d have to make sure  
that the changes would result in a perfect 1-to-1 match with what we’re  
exporting using swig.

Tom

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 21, 2014, 9:50am UTC](https://www.ruby-forum.com/t/why-swig-has-been-selected-as-c-wrapper-for-python-for-gnuradio/230496/6 "2014-06-21T09:50:32Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)
