Re: swig smart pointer inheritance issue

I spent some time reading the .cxx files swig generates, and trying to
understand how my
use of gr::digital::constellation_sptr was falling off the tracks
to other, similar applications
in the master branch (for example I
constructed a simplified
example where I was passed in gr::digital::constellation_rect::sptr,
without any subclassing to
the base constellation class, and still got type errors. Which was
puzzling. This issue didn’t seem
related to my build environment, since other examples I built using
types (floats, doubles, etc)
as parameters worked fine.

What seemed to work for me was to be very literal in declaring the
constellation class parameter
to my MER block as boost::shared_ptrgr::digital::constellation rather
than using the
constellation_sptr typedef from constellation.h. So the constructor for
MER block looks
like this:

mer::make(boost::shared_ptr<gr::digital::constellation> mod_const, 

return gnuradio::get_initial_sptr (new mer_impl(mod_const,

And can be called from from python, as I have in the following example:

from qam_demod import mer
from gnuradio import digital

cnst = digital.constellation_qpsk()
print "type© = ", type(cnst)
print "type(c.base()) = ", type(cnst.base())
m = mer(cnst.base(), 4096)

I did try importing constellation.i in the module swig .i file; this
seem to help - constellation.i
has a few template definitions for the useful constellation classes of
interest to me.

I’m still trying to understand the swig reason as to why this workaround
necessary - certainly the
section on the complications that namespaces introduce, especially so
some of the
particular examples they give about typedefs and namespaces may provide
some clues.

But at least I’m back to porting my 3.5 code to the 3.7 APIs, rather
spending time
squinting at swig’s c++ files.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs