On 2/22/08, Dan Halperin <[EMAIL PROTECTED]> wrote: > Suppose I want to build a C++ application to drive GNU Radio, using > captured trace data -- so I don't need the USRP.
> With the new top_block stuff we should be ready for this now, correct? Yep. There is actually a C++ only example in the trunk that is the equivalent of the canonical dial_tone.py example. It isn't set to compile by default, you have to edit some Makefile.am files. > 1) Since most blocks don't have public constructors, we have to indirect > through the _make_ friend functions. Is this what we want? Yes. It's not very pretty, and we've been hiding this in Python by converting: gr.null_source(...) --> gr_make_null_source(...) But the use of these factory functions to return smart pointers is so beneficial it's worth the ugliness. > 2) This example doesn't compile. There are two candidates for connect: > > /usr/local/include/gnuradio/gr_hier_block2.h:61: note: candidates are: > void gr_hier_block2::connect(gr_basic_block_sptr) > /usr/local/include/gnuradio/gr_hier_block2.h:64: note: > void gr_hier_block2::connect(gr_basic_block_sptr, int, > gr_basic_block_sptr, int) > > What does the first one do?? It only takes a single block... It is possible to connect a stand alone hierarchical block, with no inputs or outputs, into a top block so that it gets added to the flow graph. For example, you might have a transmit_path hierarchical block, which does all it needs to do internally, and a receive_path hierarchical block, which also has no inputs or outputs. To get these into top block, you would do: tb->connect(transmit_path) tb->connect(receive_path) > The second one is presumably with ports? I will try that next. Yes. > Can we > add a connect method that takes two blocks and assumes the ports are both 0? The Python 'connect' call does all sorts of wonderful Pythonic things like runtime inspection of arguments, so we can "do the right thing" on a set of arguments that includes port specifications, or just block instances. In C++, we have to rely on function overloading to do the same. It's not something I've put a lot of thought into yet, but your suggestion of adding a version of connect that takes two blocks and wires output 0 of the first to input 0 of the second is a good one. > Thoughts? I'm glad you're trying this out. It's actually been in the trunk for many months. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
