Re: [Discuss-gnuradio] usrp_basic and gr_block

[Eric Blossom]

On Sun, Jun 18, 2006 at 08:21:57PM -0500, Michael Ford wrote:
> Why are there almost no constructors defined in any of the usrp1.py classes?
> I was chugging along until I realized that most of the classes have no
> constructors. Should I be using the shared pointer classes?

[In the future please be sure to post these to the list, not directly to me.
Use the Reply-to-all command in your mail tool.]

First off, trying to read the machine generated code in usrp1.py is
a path to madness...  Don't go there.

>From the C++ point of view, they have constructors; they happen to be
protected or private.  The are only callable by their friend:
gr_make_foo for class gr_foo.  This hackery is required to ensure that
there are no non-boost::shared_ptr<gr_foo>'s floating around.  This
allows them to interact reasonably with Python's reference counting.
As a result we are able to store references to classes in both C++
data structures as well as in Python data structures without leaking
memory and/or having other object lifetime problems.

The way that we wrap the C++ with SWIG results in the gr_make_foo
function that returns a shared pointer being called automatically
instead of the protected constructor.  This all takes place
transparently.

If you care about this level of detail (since you're still trying to
get your bearings, I suggest you avoid this), you might want to look
at how one of the more simple blocks are wrapped.  E.g.,
gnuradio-core/src/lib/general/gr_add_const_ff.{h,cc,i}

GR_SWIG_BLOCK_MAGIC is defined in
gnuradio-core/src/lib/runtime/gr_swig_block_magic.i
It's not supposed to be understandable ;)

You can generally ignore all this, even when writing new blocks.  
In that case, just follow the recipe in "How to write a new block".

Eric