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
relative
to other, similar applications
in the master branch (for example ofdm_equalizer_simpledfe.cc). 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
simple
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
my
MER block looks
like this:
mer::sptr
mer::make(boost::shared_ptr<gr::digital::constellation> mod_const,
int
decim_rate)
{
return gnuradio::get_initial_sptr (new mer_impl(mod_const,
decim_rate));
}
And can be called from from python, as I have in the following example:
#!/usr/bin/python
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
didn’t
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
is
necessary - certainly the
section on the complications that namespaces introduce, especially so
given
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
than
spending time
squinting at swig’s c++ files.