Marcus, Looking around I don't see where the pointer to the block is made globally visible. I am inclined to add some code to the make method to register the shared pointer in a global variable when the method is called. Since my application has only a single USRP block (source and sink), there's no danger of overwriting something.
My problem is this: I have python code that creates the blocks and strings them together etc. but I want to actually access the created block from c++ code (in the mac block implementation). Let me know if I am seriously astray. Thanks again for your help. On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller <mar...@hostalia.de> wrote: > In GR 3.7, the shared pointer is usually blockname::sptr; > > I can't really point you to a very good example, but when you call > top_block.connect(src, sink) in C++, you're giving it spointers :) > > As I said, whenever you make a block, you actually get a shared pointer to > that instance, and not the object itself. > > > On 14.11.2013 15:39, M. Ranganathan wrote: > > Marcus, > > Thanks for your reply. What will the shared pointer be called. I see > stuff like this in the code: > > GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source) > GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink) > GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source) > > > Presumably, that generates a structure that is registered as a global > pointer. So in my mac, I want something like > > extern .... > > At the risk of asking for too much help, can you give me some guidance or > point me to a fragment of code somewhere that does this sort of thing. > > Thanks, > > Ranga > > > > On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller <mar...@hostalia.de> wrote: > >> Hi Ranga, >> >> that's what pointers are for, after all. Just do it! Thanks to the >> make()-magic you basically always have a smart shared pointer instead of an >> block object (unless you really try to break the system ;) ). >> >> Just a quick note though: MAC is usually timing-relevant. Timed commands >> might not work as you expect, so please be aware that calling >> set_command_time on your source might break functionality since there is no >> out-of-order execution. >> >> Greetings, >> Marcus >> >> >> On 14.11.2013 01:26, M. Ranganathan wrote: >> >> Hello all! >> >> I want to write a block that can directly access the uhd_usrp_source. >> This block is a mac block hence it is up on the food chain and far away >> from uhd_usrp_source in terms of its processing function. What is a good >> way of passing it a handle to the usrp_source ? >> >> I can think of some hacks (such as a static global pointer where the >> uhd_usrp_source C++ object registers itself) but it seems ugly to me to >> take that route. Is there a better way to access global objects from within >> a block implementation. >> >> Thanks in advance for any help. >> >> Regards, >> >> Ranga >> >> -- >> M. Ranganathan >> >> >> _______________________________________________ >> Discuss-gnuradio mailing >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > M. Ranganathan > > > -- M. Ranganathan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
