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