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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio